Re: [PATCH 03/23] sdlaudio: add -audiodev sdl, out.buffer-count option

["Volker Rümelin" <vr_qemu@t-online.de>]

>    Hi,
>
>> -    hw->samples = obt.samples;
>> +    hw->samples = (spdo->has_buffer_count ? spdo->buffer_count : 4) *
>> +        obt.samples;
>> +# @buffer-count: number of buffers (default 4)
> Any specific reason for this default?
>
> In my testing I've needed much higher values.
> 8 still got me crackling sound, 16 worked ok.

Hi Gerd,

this was an attempt to come up with SDL audio settings which work for 
all SDL audio drivers. Unfortunately, the different SDL audio drivers 
have different timings and there are no default settings that work for 
all of them. Here are two examples where buffer-count=4 works.

On my Linux system I use

export SDL_AUDIODRIVER=pulse
and start qemu with -device intel-hda -device hda-duplex,audiodev=audio0 
-machine pcspk-audiodev=audio0 -audiodev 
sdl,id=audio0,out.buffer-length=3750

Due to the mix-up of samples and frames in audio/sdlaudio.c the callback 
buffer has a size of 2 * 3.75ms = 7.5ms and SDL calls the callback 
function every 7.5ms. With out.buffer-count=4 that's a 4 * 7.5ms = 30ms 
buffer on the qemu side. This is larger than the minimum size of 
timer-period.

On Windows the timing is different. The time between SDL callback calls 
is a multiple of 10ms. I have to use

export SDL_AUDIODRIVER=directsound
and start qemu with -device intel-hda -device hda-duplex,audiodev=audio0 
-machine pcspk-audiodev=audio0 -audiodev 
sdl,id=audio0,timer-period=1000,out.buffer-length=5500

With the above settings the playback stream sometimes will see 2*10ms + 
1ms stalls. The qemu hda codec can barely handle this. On average it 
will drop playback data after 23.22ms.

With best regards,
Volker

> take care,
>    Gerd
>