On Mon, 9 Nov 2020, Andrew Eikum wrote: [...]
I'm not strongly opposed to removing them, but how about we try to improve how they track wall time? Something like the attached patch.
It's better with that patch but still fails quite often.
To test this I focused on the first GetPosition() test, tweaked the ok() messages to show the position in milliseconds too, added a trace of the ratio of GetPosition() / slept (which we expect to be below 1.1 or at least 1.4), added a patch to loop 100 times over this test, and still did 3 runs. See the attached:
0001-mmdevapi-render-Trace-the-position-in-milliseconds-t.patch 0002-mmdevapi-render-Make-sure-to-get-an-upper-bound-on-t.patch 0003-mmdevapi-render-Loop-and-trace-ratio-between-positio.patch
On Windows 10 in QEmu this shows the test still often goes above the 1.4 limit.
See: since-win10+qemu+local.png
So then I tweaked the slept interval to start right before the Start() call (which takes 1.5 to 3 ms), and end right after GetPosition() returns. This way we are sure that slept is an upper bound on the pos value.
That improves the share=0 case but paradoxically the share=1 case sees more spread and higher values. There may have been more activity on the host but then I would have expected this to impact the share=0 case too. In each case we still get at least 1 value that's too high and many that are close:
See: upper-win10+qemu+local.png
(I also tested this with an ich6 virtual QEmu sound card but it made no difference)
The same test on real hardware (Windows 10 on cw-gtx560) shows radically different results, results that are actually in line with the test expectations:
See: upper-win10+gtx560.png
So rather than just apply these patches and blindly increase the margin factor I dug some more to try to understand what is really going on. I'll try to get my theories and findings in shape in my next email.
