http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #126 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-25 09:19:44 CST --- I've attached to bug #27937 my newest set of render tests that you'll also find in testbot job #16643. It implements the XAudio2/Rage scenario as described by Alexey in comment #19.
Doing so, I found out that it was an error to ignore clock slew. It appears that CreateTimerQueue is no good time base. It never caused wake-ups after 10ms on my system. Using CreateTimerQueue(... mmdevapi_ms - 3 (=7ms) ...) produced wake-ups every 8ms approx., anything higher lead to 12ms. Never in-between. Of course, 12ms produced regular underruns, as XAudio2 only adds at most 10ms at every event. Frequency scaling from min to max showed no change.
IOW, to support the XAudio2 scenario = "add at most one period per event", we MUST deliver events *exactly* based on audio frame consumption, or faster! (or auto-adjust based on Release'd frames).
I don't really understand the current code
What part? Arguably, err < 0 after set_*_near should be fatal, because ALSA will oblige out of range parameters, unlike the non-near parent.