[hatari-devel] Slow sound buffer

David Savinkoff dsavnkff at telus.net
Tue May 11 22:55:34 CEST 2010


An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100511/551770d5/attachment.html>
-------------- next part --------------
************
On Tue, 11 May 2010, David Savinkoff wrote:

> Hi,
>
> > Theoretically, 508/512 should give 46 ms delay at 11 kHz, which should
> > not be noticeable. If you can hear it, then the delay is bigger than what
> > SDL reports.
> >
> I guess the delay is caused by drifting to maximum delay with
> MIXBUFFER_SIZE = 16384 and not SoundBufferSize = 512.
> (the larger either is, however, the longer the delay)

I have some doubt on the "drift" effect over time. If delay was drifting,
I don't see anything in the code that would prevent it from drifting
forever. Except is would drift modulo MIXBUFFER_SIZE.
So, delay would increase, go back to 0, increase again, ...

But from what you report, delay seems constant over time, so for me this
looks like a problem at SDL's init that create a delay once for all and
then this delay doesn't change after. Maybe SDL/alsa is dropping some
frames at start in your case and is never able to regain those lost
frames.

Assuming we try different values instead of 46 ms at 11 kHz, could you try
these values for "samples" and see if you have better results.

20 ms : samples = 221
10 ms : samples = 111

If this gives better results, I could add a parameter to specify sound
latency (but I would be interested to know first if this can be fixed by
using sdl 1.2.14)

************
Reply
************

Hi,

I'm looking at the Audio_CallBack(), line 33, in audio.c as I say what
is on my mind here.

When nGeneratedSamples >= len, enough samples are available, so pass
completed buffer to audio system. However, what happens if Hatari
continues to provide more samples than the callback swallows?
I believe we have to slow down Hatari's sample rate to let the callback
catch up. The opposite is true when too few samples are generated.
Otherwise the buffer drifts to the extreme of Not enough samples
available, or too many (which can cause a delay and lost samples).
Thus, three sample rates (slower, exact, faster) are needed for each
of which hatari already has (eg. 44090 44100 44110 Hz) while SDL only
sees the exact frequency.

When nGeneratedSamples > len  ; go slower
When nGeneratedSamples < len  ; go faster
When nGeneratedSamples == len ; otherwise be exact

Note that the exact frequency is needed to reduce 'hunting' or
excessive correcting.

Maybe this problem will have to be corrected after the release.


I am able to compile SDL-1.2.13 with my gcc toolchain but not SDL-1.2.14
I'm stuck with SDL-1.2.13

David Savinkoff



More information about the hatari-devel mailing list