http://bugs.winehq.org/show_bug.cgi?id=28039
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-23 02:21:57 CST --- Created attachment 37588 --> http://bugs.winehq.org/attachment.cgi?id=37588 render.ok test output of my extended mmdevapi tests
My mmdevapi position tests now mostly pass, great. What's striking is that position is generally equal to sum of written frames - GetCurrentPadding. This is not unlike native's exclusive mode. Perhaps you want to check for rounding errors because it's sometimes off by one as in: render.c:1143: padding 17617 position 17420/17421 slept 550ms iteration 1 render.c:1143: padding 17622 position 30700/30701 slept 850ms iteration 4 Or is that simply an effect of time advancing between 2 calls?
I've yet to spend more time, but I've noticed that if you increase the big sleep prior to my rendering loop from 350 to 450ms, there's a test failure at iteration 1 (normal after an underrun) but also at iteration 2: render.c:1151: Test failed: Position delta 4933 not regular That does not make GetPosition appear like a true speaker position. It should not advance by more than 4454 frames in 101ms.
You may want to increase the sleep even more to see that it's a bit odd: render.c:1090: data at 0x421dc000 for prefill 20671 render.c:1119: hpctime 551 after 550ms render.c:1138: hpctime 651 pcpos 651 render.c:1143: padding 0 position 20671/20671 slept 650ms iteration 0 render.c:1172: data at 0x421dc000 render.c:1138: hpctime 752 pcpos 752 render.c:1143: padding 15086 position 26255/26256 slept 750ms iteration 1 render.c:1151: Test failed: Position delta 5584 not regular After an underrun, GetPosition increases too fast (perhaps frames are silently skipped when a buffer's start time lies in the past).