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.