[hatari-devel] Slow sound buffer

[Nicolas Pomarède]

Le 03/01/2011 09:06, David Savinkoff a écrit :
> Hi,
>
> I have tested and solved this problem on my system with hatari 1.4.0
> and the latest sources.
>
> ****
> In audio.c :
> SoundBufferSize = desiredAudioSpec.size;
> SoundBufferSize /= 4;
>
> Is replaced with:
> SoundBufferSize = desiredAudioSpec.samples;
>
> I believe the intention now agrees with the result (as it still works) :)
>
> ****
> In sound.c :
> MixBuffer[][] latency is now controlled.
>
> The change here is what controls the sound latency without
> compromising sound quality. I now get tactile sound response
> from the keys when i use tos206.us (60 Hz) at any sampling rate.
>
> For approx 16 millisecond response I use:
> hatari --sound-buffer-size 16
>
> or place:
> nSdlAudioBufferSize = 16
> in:
> hatari.cfg
> ****
> David


Hello,

I agree that the first patch for audio.c should not cause problem (it's 
mostly cosmetic) since samples * 4 = size in our case.

But regarding the modification you propose in sound.c, I'm still not 
convinced that it's the correct way to go.

Going back to the discussion we had in may 2010, I still don't find it 
logical that changing the size of the internal Hatari's working buffer 
should affect the output sound from SDL.

I agree that changing the desired "samples" (with nSdlAudioBufferSize) 
will impact the latency and the rate at which SDL audio callbacks are made.

But I still consider that reducing the size of the working buffer is 
just hiding a real problem by a shorter size of the ring buffer.

In your case, using (SoundBufferSize<<1) might be good, but what if some 
(buggy ?) alsa drivers for other sound cards had a delay twice as big as 
yours ? With a shorter working buffer and a bigger delay than yours, it 
could be completly possible that we overwrite data currently being 
played by SDL by the new data being computed by Hatari in sound.c

Maybe this constant delay you have is something that can only be 
controled at the alsa level, or maybe a newer SDL version would handle 
alsa better if that's the cause ?

Have you been able to test with a more recent kernel or with SDL 1.2.14 ?
Also, do you have the possibility to install pulseaudio to see if you 
get better results than when using alsa directly ?


Nicolas