[hatari-devel] Slow sound buffer
npomarede at corp.free.fr
npomarede at corp.free.fr
Sun May 9 19:28:11 CEST 2010
On Sat, 8 May 2010, David Savinkoff wrote:
> Hi,
>
> More bugs that can lead to buffer overflows and unexpected weirdness:
>
> $ find . -print0 | xargs -0 grep SoundBufferSize
> ./src/audio.c:int SoundBufferSize = 1024; /* Size of sound buffer */
> ./src/audio.c: SoundBufferSize = desiredAudioSpec.size; /* May be different than the requested one! */
> ./src/audio.c: if (SoundBufferSize > MIXBUFFER_SIZE/2)
> ./src/sound.c: nGeneratedSamples = SoundBufferSize + SAMPLES_PER_FRAME;
> ./src/sound.c: nGeneratedSamples = SoundBufferSize + SAMPLES_PER_FRAME;
> ./src/includes/audio.h:extern int SoundBufferSize;
> $ find . -print0 | xargs -0 grep SAMPLES_PER_FRAME
> ./src/sound.c:#define SAMPLES_PER_FRAME ((nAudioFrequency+35)/nScreenRefreshRate)
> ./src/sound.c: nGeneratedSamples = SoundBufferSize + SAMPLES_PER_FRAME;
> ./src/sound.c: nGeneratedSamples = SoundBufferSize + SAMPLES_PER_FRAME;
> ./src/sound.c: nSamplesPerFrame = SAMPLES_PER_FRAME;
>
> Note that:
> 1) SoundBufferSize is in units of [bytes] but is initialized in [samples].
> 2) nGeneratedSamples = SoundBufferSize [bytes] + SAMPLES_PER_FRAME [samples];
>
Hi,
indeed it seems that when we went from 8 bit mono do 16 bit stereo,
desiredAudioSpec.size was not converted back to sample.
Theorically, this should only mean we get approx 5 frame delay instead of
2, which is not hearable in my case, but seems to be in your case.
When sound is changed, I get :
current version at 44.1 kHz :
Sound_ResetBufferIndex SoundBufferSize 3760 SAMPLES_PER_FRAME 882 nGeneratedSamples 4642 , ActiveSndBufIdx 3901
patched version at 44.1 kHz :
Sound_ResetBufferIndex SoundBufferSize 940 SAMPLES_PER_FRAME 882 nGeneratedSamples 1822 , ActiveSndBufIdx 1554
current version at 44.1 kHz :
Sound_ResetBufferIndex SoundBufferSize 1408 SAMPLES_PER_FRAME 221 nGeneratedSamples 1629 , ActiveSndBufIdx 10708
patched at 11 kHz :
Sound_ResetBufferIndex SoundBufferSize 352 SAMPLES_PER_FRAME 221 nGeneratedSamples 573 , ActiveSndBufIdx 6857
So, ActiveSndBufIdx is less "ahead" which means a shorter delay of approx
3 VBL for me.
Can you apply this patch and see if it changes things for you (and give
the debug output at 11 kHz and 44 kHz) ?
In case you still have a delay, does it disappear if you do a cold reset
of the Atari system ?
--- ../../hatari-in/src/audio.c 2010-04-05 14:48:50.966965365 +0200
+++ ./audio.c 2010-05-09 19:14:42.046663260 +0200
@@ -21,7 +21,7 @@
int nAudioFrequency = 44100; /* Sound playback frequency */
bool bSoundWorking = false; /* Is sound OK */
volatile bool bPlayingBuffer = false; /* Is playing buffer? */
-int SoundBufferSize = 1024; /* Size of sound buffer */
+int SoundBufferSize = 1024 / 4; /* Size of sound buffer */
int CompleteSndBufIdx; /* Replay-index into MixBuffer
*/
@@ -121,6 +121,7 @@
}
SoundBufferSize = desiredAudioSpec.size; /* May be different than the requested one! */
+ SoundBufferSize /= 4; /* bytes -> samples (16 bit signed stereo -> 4 bytes per sample) */
if (SoundBufferSize > MIXBUFFER_SIZE/2)
{
fprintf(stderr, "Warning: Soundbuffer size is too big!\n");
More information about the hatari-devel
mailing list