mmdevapi:render test failures

[Francois Gouget]

Takeaway and todos from the previous email:
(TL;DR; sort of)

* QEmu 5.0 is buggy: audio playback stalls if no Spice client is 
  connected.
  -> Report the bug to QEmu.

* This causes failures in the w10pro64 VM.
  -> QEmu 3.1 does not have this bug but w10pro64 was created with QEmu 
     5.0 so I'm not sure a downgrade can work (iirc it at least causes 
     an error when I try to power it up).
  -> So I think I will switch w10pro64 to VNC instead since that works
     around the bug too.

* When there is a Spice or VNC client ~40 ms of audio is buffered when 
  the playback starts. That's why we need to allow up to 140 ms of audio 
  playback for our 100 ms playback test. Importantly this has nothing to 
  with scheduling delays caused by QEmu or whatever.

* The buffering seems unavoidable when a client is connected to the VM. 
  But during the normal TestBot operation no client is connected. In 
  that case QEmu should be able to skip the buffering but does not.
  -> That could be a QEmu improvement.
     This may be too specific to our needs and thus may not be accepted
     upstream.
  -> Investigate anyway? Submit an RFE?

* After the initial buffering the playback proceeds at a normal rate.
  -> Either increase the initial margin from 1.4 to at least 1.5.
  -> Or modify perform the playback rate tests after a 120 ms 'ramp up 
     delay'.
  -> The latter may not be practical when testing what happens when 
     stopping and restarting playback.

* This analysis is applicable to all the audio playback tests that look 
  at playback timings.

* The capture tests may run into similar issues too.

* Winepulse in QEmu seems to be immune to this initial buffering for 
  unknown reasons.

-- 
Francois Gouget <fgouget at codeweavers.com>