http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #88 from Andrew Eikum aeikum@codeweavers.com 2011-12-15 15:32:31 CST --- (In reply to comment #87)
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.
I see. Perhaps the combination of _min() and _near() that you suggest is the best solution.
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).
Okay, I'll merge them and create another patchset tomorrow morning. Hopefully we can agree on it and get it off.
Alexey, are you okay with taking ownership of patch 1 and sending it in this weekend?
get it in ASAP
This Friday's 1.3.35 would be nice.
Probably too late for that, but I'm fine with next Monday.