mmdevapi:render test failures

[Francois Gouget]

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.


-- 
Francois Gouget <fgouget at codeweavers.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: since-win10+qemu+local.png
Type: image/png
Size: 55931 bytes
Desc: since-win10+qemu+local.png
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201116/4b72709f/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upper-win10+qemu+local.png
Type: image/png
Size: 65959 bytes
Desc: upper-win10+qemu+local.png
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201116/4b72709f/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upper-win10+gtx560.png
Type: image/png
Size: 48151 bytes
Desc: upper-win10+gtx560.png
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201116/4b72709f/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mmdevapi-render-Trace-the-position-in-milliseconds-t.patch
Type: text/x-diff
Size: 4532 bytes
Desc: 0001-mmdevapi-render-Trace-the-position-in-milliseconds-t.patch
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201116/4b72709f/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-mmdevapi-render-Make-sure-to-get-an-upper-bound-on-t.patch
Type: text/x-diff
Size: 1698 bytes
Desc: 0002-mmdevapi-render-Make-sure-to-get-an-upper-bound-on-t.patch
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201116/4b72709f/attachment-0004.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-mmdevapi-render-Loop-and-trace-ratio-between-positio.patch
Type: text/x-diff
Size: 2945 bytes
Desc: 0003-mmdevapi-render-Loop-and-trace-ratio-between-positio.patch
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201116/4b72709f/attachment-0005.patch>