[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