[hatari-devel] Slow sound buffer

[Nicolas Pomarède]

Le 05/01/2011 08:02, David Savinkoff a écrit :
> Happy New Year All
>
> Hi Nicolas,
>
>> I agree that changing the desired "samples" (with nSdlAudioBufferSize)
>> will impact the latency and the rate at which SDL audio callbacks are
>> made.
>
> 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
> has delays.
>
>> 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][2] 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
> overwrite SDL.
> 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 ***
>

Hello,

I don't say your patch doesn't work, it certainly works for you and I'm 
sure it would work for me.
Basically, it just decreases the number of sound buffer to approx 16 
today (16384 / 1024) to sthg around 3 buffer.

Hatari can't produce more or less samples than the sound system expects, 
it's Hatari that choose the number of samples that must be produced and 
the system should follow this, not the opposite.

If hatari produced in my case less sample than my system consume, then 
it would be completly hearable, with "clicks" on every VBL.

The problem with this patch is that :

  - we can verify it works on your machine, on mine and on everyone's on 
the list. But we can't verify it works everywhere, so we have no real 
way to validate it 100%.

  - it addresses a problem that to me seems related to a faulty alsa 
driver and/or SDL version.
SDL 1.2.13 is 3 years old (!) and kernel 2.6.18 is 4 years old (!). Im' 
sorry, but we can't make changes to Hatari to fix problem that could be 
related to such old version


I'm not against trying to find a way to fix this issue, but at least we 
must first have similar environments (kernel/SDL) to compare. There 
would be no point in patching Hatari for things that could have been 
resolved already in newer version of kernel/SDL.

Regards

Nicolas

>
> Thank You,
> David
>
> I'm using:
> CentOS 5.5
> pulseaudio-0.9.10
> SDL-1.2.13
> kernel-2.6.18
> Creative Live Drive IR (Sound Blaster) with dsp 56k sound
> pentium3 1GHz
>
> Will have to wait to migrate to CentOS 6.0, I can't compile SDL-1.2.14