http://bugs.winehq.org/show_bug.cgi?id=28039
--- Comment #7 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-17 16:16:17 CST --- The remaining issue becomes obvious when increasing the sleep even more, e.g. to 3150ms: render.c:1090: data at 0x422dc000 for prefill 20671 render.c:1119: hpctime 3151 after 3150ms render.c:1138: hpctime 3252 pcpos 3252 render.c:1143: padding 0 position 20671/20671 slept 3250ms iteration 0 # normal padding 0 past underrun render.c:1138: hpctime 3352 pcpos 3352 render.c:1143: padding 0 position 41342/41342 slept 3350ms iteration 1 render.c:1166: Test marked todo: GetBuffer large (20671) at iteration 1
WineCoreAudio 1.3.35 pretends advancing by 20671 frames within 100ms(!), as if underrun had never occurred during the last 3 seconds.
render.c:1138: hpctime 3453 pcpos 3453 render.c:1143: padding 0 position 62013/62013 slept 3450ms iteration 2 render.c:1166: Test marked todo: GetBuffer large (20671) at iteration 2 render.c:1138: hpctime 3553 pcpos 3553 render.c:1143: padding 0 position 82684/82684 slept 3550ms iteration 3 render.c:1166: Test marked todo: GetBuffer large (20671) at iteration 3 ... advancing by 1.5 seconds worth of frames within 300ms.
This behaviour is bogus and reminds of ALSA's dmix at the time Wine used the "play silence during underruns" mode instead of XRUN that I reported in bug #28517, comment #4. There too, the app could throw megabytes of data to the audio engine, normalizing only once as many frames had be written fast as the underrun gap had caused. A difference probably is: ALSA plays silence, CoreAudio might buffer all that stuff and play it late. I can't tell as my render tests are solely playing silence.
The resulting behaviour is very different from native and may cause havoc with apps using winmm, because GetPosition governs WHDR_DONE messages. They will be sent out too fast after an underrun occurred, causing loss of sync and other effects.
The good news is that GetPosition will not report a position higher than the number of written frames.