[hatari-devel] Slow sound buffer

npomarede at corp.free.fr npomarede at corp.free.fr
Tue May 11 23:21:52 CEST 2010


On Tue, 11 May 2010, David Savinkoff wrote:

> 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

Hello,

were you able to try those shorter values to see if they make things 
better ?

> 
> 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.

Theorically, I agree that if the system is not able to play sound at the 
same rate they're generated by the emulator then we'll get a delay (or not 
enough sample to play).
But if Hatari generates samples at 44.1 kHz and SDL audio is set to 44.1 
kHz, there should not be noticeable delay. I think alsa/sdl is precise 
enough to have the callback function called at the requested rate.

If such a drift occurs (I agree it can happen), changing freq could be a 
bad idea though ; maybe it wouldn't be heard when playing samples, but for 
ym sound using envelopes or sid effect, I think this could alter the sound 
and be noticeable as those "raw" sound can sometimes combine complex 
sin/square waveforms.

This problem is not unique to hatari, video player can run in the same 
troubles. In that case, I think the policy is to drop some bytes in the 
buffer to be played or to insert silence in this buffer to get as many 
samples as needed by the callback function (this could be interesting to 
have a look at mplayer's source code on this point)

In the case of alsa, I have the feeling that the callback rate is adapted 
to get an exact 44.1 kHz frequency by asking for more or less bytes each 
time (if I recall correctly the value of "len" changes in Audio_CallBack 
if you printf it)

But then, in my daily use, I never experienced such audio synching 
problem, whether with hatari or mplayer for example. For recent computer, 
playing sound at a fixed rate should not be a problem, if errors are 
hearable, I think a part of this could be due to the driver / hardware for 
the sound card.


> 
> 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

Do you have the possibility to use a recent live cd (ubuntu, whatever you 
like, ...) and try the binary of Hatari you compiled earlier on your 
system ? It could be interesting to see if the problem remains with a 
recent linux distrib, this could be an alternative to building sdl 1.2.14


Nicolas


More information about the hatari-devel mailing list