[hatari-devel] Slow sound buffer
dsavnkff at telus.net
Wed Jan 5 08:02:54 CET 2011
Happy New Year All
> I agree that changing the desired "samples" (with nSdlAudioBufferSize)
> will impact the latency and the rate at which SDL audio callbacks are
Without my patch nSdlAudioBufferSize works to some extent on my
system (slight improvement). With my patch... latency solved.
BTW the number of samples delay may be constant, not the time
delay. Faster sample rates have less delay.
I'm of the opinion that hatari produces more samples than my
sound system consumes, and hatari may produce fewer samples than
your sound system consumes. Thus I get a MIXBUFFER_SIZE delay
and you get a possible "sample losing, zero delay". Note that
both mine and your systems can lose samples. My system could
lose samples after the delay gets huge, yours immediately.
This is noticeable on my system when I use tos206uk.img (50Hz)
vs tos206us.img (60Hz); tos206uk.img has no delays, tos206us.img
> With a shorter working buffer and a bigger delay than yours, it
> could be completely possible that we overwrite data currently being
> played by SDL by the new data being computed by Hatari in sound.c
The patch simply prevents the buffer output pointer from getting too
far behind the input pointer by controlling nSamplesToGenerate.
- nSamplesToGenerate = MIXBUFFER_SIZE - nGeneratedSamples;
+ nSamplesToGenerate = (SoundBufferSize<<1) - nGeneratedSamples;
(SoundBufferSize<<1) must be no greater than MIXBUFFER_SIZE or
MixBuffer[MIXBUFFER_SIZE] will overflow. MIXBUFFER_SIZE must
also be divisible by (SoundBufferSize<<1) without a remainder.
Note that MIXBUFFER_SIZE in the code above is the Maximum possible
value, not the only acceptable value.
To address 'overwriting data currently being played by SDL':
1) A system that doesn't produce enough samples for SDL will not
2) A system that produces excessive samples for SDL will have a delay
that gets smaller with a smaller working buffer, and will not overwrite
SDL because Audio_CallBack(void *userdata, Uint8 *stream, int len)
is in control.
Both systems can lose samples when the working buffer MixBuffer
either underflows or overflows...(halts/wraps/overwrites/?). Thus the
need to control nSamplesToGenerate.
Addressing a hidden real problem:
If this patch doesn't break any systems, given hidden real problems or
not, and fixes systems presenting excessive latency, then maybe this is
the solution. Proving this patch wrong is easier than proving it right.
*** Please try the patch to at least put it out of its misery ***
Creative Live Drive IR (Sound Blaster) with dsp 56k sound
Will have to wait to migrate to CentOS 6.0, I can't compile SDL-1.2.14
More information about the hatari-devel