winealsa: Don't set ALSA's period time.

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Thu Nov 3 03:41:46 CDT 2011


Hi,

perhaps I shouldn't send this one day before release...

I argue that Wine has no business setting ALSA's period size,
esp. not to a completely random value like duration/10.
Better leave it complete freedom, as confirmed in
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-August/042837.html

What I think may be interesting is set min and/or max of the *buffer* time, e.g.
set_buffer_time_min = 2*period (hmm?)
set buffer_time_max = 100ms

The max buffer time may be interesting for 2 reasons:
 - perhaps it prevents PA from using its typical 2s buffer (I've yet to test that)
 - there's still the need for the patch to prevent AC_Stop from using snd_pcm_drop thus losing frames,
as noted in http://www.winehq.org/pipermail/wine-devel/2011-August/091565.html
There's a choice:
a)  either have AC_Stop enter XRUN when all frames are played
b) or use snd_pcm_pause().

Clearly, pause is closer to the semantics of native, but makes the state mapping
in winealsa more complex. XRUN is more like a no-op. To help XRUN on Stop, ALSA should not
buffer too many frames, that's where buffer_time_max comes into play. 100ms looks small enough.
If PA would receive and buffer 2s of audio data, clearly Stop as XRUN is not the right choice.

Regards,
 Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-winealsa-Don-t-set-ALSA-s-period-time.patch
Type: application/octet-stream
Size: 1584 bytes
Desc: 0001-winealsa-Don-t-set-ALSA-s-period-time.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20111103/a0580994/attachment.obj>


More information about the wine-patches mailing list