mmdevapi:render test failures

[Francois Gouget]

So mmdevapi:render keeps failing randomly due to timing issues.
All the random failures seem to follow this model:

render.c:1091: Test failed: Position 50880 too far after playing 100ms

1077    hr = IAudioClient_Start(ac); /* #1 */
1080    Sleep(100);
1081    slept += 100;
1087    hr = IAudioClock_GetPosition(acl, &pos, NULL);
1090    /* in rare cases is slept*1.1 not enough with dmix */
1091    ok(pos*1000/freq <= slept*1.4, "Position %u too far after playing %ums\n", (UINT)pos, slept);

There are a number of issues with that test:

* Sleep(100) never sleeps for 100 ms!
  It either sleeps for 93.6, 109.2 or even 124.8 ms depending on the 
  Sleep() history. In any case it's always a multiple of 15.6 ms. So 
  line 1081 is wrong.

* IAudioClient_Start() takes between 1.5 and 3 ms. There is no telling 
  when the audio actually starts during that interval. So that adds up 
  to 3 ms to the play time.

* In turn that means the 1.4 factor on line 1091 does not provide a 
  'safety margin' but really only compensates for the bug on line 1081.

* And in any case, given the very short duration, I feel this is going 
  to test how the driver / hardware deals with buffering and latency 
  more than anything else. (even if the driver claims the latency is 0)


So what is the goal of that test? I mean besides "Perform renderer 
padding & position tests".

Is the goal to check that an 8-bit stereo stream is not being played as 
a 16-bit stereo stream, i.e. twice as fast as it should?

Then, assuming we find a suitable duration for that test, wouldn't it 
make more sense to set the leeway factor to something between 1.5 (an 
even split between expected (1) and too fast (2)) and 1.8 (i.e. biased 
to account for buffering & co).

And we should be measuring how much time elapsed between just before the 
Start() call and right after the GetPosition() one to set our 
expectations.


Or... scrap the test?


-- 
Francois Gouget <fgouget at codeweavers.com>