http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #33 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-06 14:57:25 CST ---
Using more artificial (and even more incorrect) construct like this
Actually I believe it's quite close to correct, except for the -1.
Here's what I believe would happen to your scenario from comment #24 in native (with >=10.500ms period, duration x4 but let's compute with 10ms periods): 0. Before start, the app prefills 30ms according to your comment #19. At time ~0, 10ms of data is fed to the mixer, then the HW, so 20 from the initial 30ms of data remains -- for the next 10ms, native GCP will report 20ms padding.
- Timer event #0 is late by 1.1ms. At the moment callback is called 1.1ms of
data had been actually played, 28.9ms left. ... so reported padding would still be 30ms
Native GCP returns 20ms.
2. Timer event #1 is late by 0.5ms. At the moment callback is called 10.5ms of
data had been actually played back, 19.5ms left. Due to alsa period padding value reported by ALSA is ~21ms. XA2 sees that the buffer have not enough space to fit another 10ms of data, does nothing.
Native GCP report 10ms (441 frames), not 21. Hence according to your comment #16, XA2 writes 10ms of data.
- Timer event #2 is late by 0.1ms. At the moment callback is called 20.1ms of
data had been actually played back, 9.9ms left. Reported padding value is ~12ms. XA2 pumps in 10ms of data to the winealsa.drv local buffer.
Native GCP reports 10ms, again causing XA2 to add another 10.
From there on, XA2 will add 10ms at every event.
Whether the app is called late doesn't matter. It has nearly 9.9ms to supply data. All that matters is that the native mixer calls the HW in time. MS lets it run at one of the highest system priorities to ensure that audio will not present hickups. Wine can't run anything at such a priority, but it can change it's padding to accommodate XA2 and look more like native.