http://bugs.winehq.org/show_bug.cgi?id=30836
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #13 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-24 16:27:16 CDT --- Andrew, seeing this bug I understand why you'd like to get that other patch into Wine. Yet it's unclear to me what exactly makes it work: your patch does 2 things, the rate limiting and some changes to ALSA buffer sizes and periods. I mean, it could work by side-effect rather than due to actual rate limiting.
Your analysis appears very plausible.
It sometimes takes more than a period for the ALSA driver to update its IAudioClient::GetCurrentPadding().
"sometimes" because of jitter or why? Or because the ALSA buffer may be filled with the effect that mmdevapi:GetCurrentPadding may not decrease for 2-3 mmdevapi periods or at least one ALSA period (which could be as much as 100ms)? In that case, we should conclude that it's a bug for mmdevapi:GetCurrentPadding not to decrease as regularly as native's. My point is that there can be solutions to this independently of rate-limiting, e.g. I imagine a driver that decrements padding exactly once per event by one period worth of frames and adapts its event rate to +/- 20% actual drain by the underlying ALSA driver.
DSound should be somewhat independent on mmdevapi. All apps named here do not see mmdevapi directly rather than DSound. So it's clearly a bug of DSound's GetCurrentPosition not to change as regularly as the "Direct HW ping pong buffer" abstraction would suggest. That might be tackled independently on mmdevapi.
The (unsurprising) lesson is: it's not enough to satisfy the API. The apps very much depend on comparable dynamic behaviour.