The sad state of audio GetPosition

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

here's just for fun an interpretation of some test data:

A native machine passes all my tests in shared mode.

In exclusive mode, that machine behaves like PulseAudio in Wine now :-)
render.c:797: BufferSize 21846 frames
render.c:799: Test failed: BufferSize 21846 too small for duration at rate 44100
render.c:807: Clock Frequency 44100
render.c:872: Test failed: Position 21829 too far after 100ms
render.c:882: padding 0 past sleep #2

It ate 495ms worth of samples (the completely prefilled buffer - mysterious 17)
within 100ms after Start then returned a local underrun (padding 0)!
Clearly a bug in MS-Windows or some driver.

If you start with an underrun like my loop does, then
that machine returns data that appears valid:
render.c:1033: padding 1324 position 19648 slept 470ms iteration 0


Testbot shows how MS "fixed" a bug between Vista and w2k8R2/w7 in exclusive mode:
render.c:1086: Test failed: GetCurrentPadding returned 576, should be 0
render.c:1092: Test failed: Position 90720 at end vs. 91296 played frames
Somewhat I found the old behavior more consistent.
After all, 90720 + 576 = 91296

What's noteworthy is that only a multiple of period frames appears to
get written.  Unlike shared mode, the remainder will be left in the
buffer, even if you wait for an underrun to occur (like my tests do).

IOW, native players using exclusive mode are well-advised to add a few
silence frames at the end of the samples, or they won't be heard.
At least, that's what I infer from
render.c:1092: Test failed: Position 90720 at end vs. 91296 played frames
since I've never put my hands on a native system new enough to have mmdevapi.


Testbot confirms again that you must not trust timers in vmware,
which I already experienced with the MCI tests.
render.c:1040: hpctime 828 pcpos 843
render.c:1033: padding 16560 position 50832 slept 870ms iteration 4
render.c:1034: Test failed: Position 50832 too far after 870ms
render.c:1035: Test failed: Position delta 7392 not regular
render.c:1040: hpctime 937 pcpos 952

Within 109ms its speaker position advanced by 7392 frames,
whereas 5232 would be normal at 48000 in that time frame.

Other than that, data looks good.

It will be no fun to correct the tests to accept testbot's daily results on test.winehq.
Currently I lean towards
    if (winetest_debug > 0)
        position-tests
such that testbot's patch watcher skips over position-based
tests which we would know pass on native.

Regards,
	Jörg Höhle