http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #87 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-15 03:48:17 CST ---
But _near() runs the same risk as _max(), that is, it allows ALSA to give us too small a buffer (Bug 28282).
Do you mean? fixme:alsa:AudioClient_Initialize ALSA buffer time is smaller than our period time. Expect underruns. (352 < 441) I thought this is caused by the bogus period=duration/10. With duration/10 gone, I believe ALSA will heed our advice.
Perhaps we should enforce set_buffer_size_min = 2 * mmdevapi_period in addition to set_buffer_near? But I've not yet thought about the theoretical lower limits that ensure a continuous stream.
Other than wasting memory, what's the harm of a 2s buffer since we limit our writes in alsa_write_data() anyway?
SW may select varying behaviour based on the hints it gets. IIRC MSDN says that duration is a hint that allows to select between fast & "don't care" behaviour; XAudio2 changes behaviour when period > 10.5ms. Perhaps PA too? That's why I consider it important to give adequate hints. In comment #72, I've myself proposed changing behaviour when duration<=80ms.
do you think they should block this patchset?
No. Mastering buffer size is another topic than mastering PA.
I can't take ownership of 0002 for as long as it contains the bogus if(period) logic that goes against my current knowledge. Either merge 0002 and 0004, or perhaps wait for my 0000 patch that sets period & duration limits properly. The missing piece from 0000 is the exact upper limit on period and duration sizes in exclusive mode (which do not look like what MSDN documents about Initialize).
My yesterday buffer size tests have shown: shared mode: duration is min. 3*periods on testbot excl. mode: duration is min. 8*periods! That shows how much the MS developers thought would be needed to provide stable output.
get it in ASAP
This Friday's 1.3.35 would be nice.
submit them one-per-day
I don't believe that's needed as e-mail does not guarantee ordering. If we all send numbered patches, the committer should apply them in order.
When that'll be done, more patches will be needed - IAC_Stop no snd_pcm_drop (in my queue) - alsa_period filler to ensure ALSA starts - alsa stalling detection - change OSS accordingly