Maarten,
- hres = IAudioClient_GetStreamLatency(device->client, &period);
device->sleeptime = period_ms * 5 / 2;ret = WaitForSingleObject(dev->sleepev, dev->sleeptime);
Although it's a minor point, as we're solely discussing the case of the timeout when mmdevapi doesn't call SetEvent, I wonder why you insist on using GetStreamLatency as the basis of your timeout computations instead of GetDevicePeriod.
You know that wineXYZ.drv use the device period as the basis for their SetEvent, thus IMHO the timeout too should be based on it, instead of a GetStreamLatency we know next to nothing about.
If you visit testbot jobs 23521 and 23514, you'll see that I've measured the event rates. Sadly, all testbot VMs report a GetStreamLatency of 10.6666ms too close to the DefaultPeriod of 10.0000ms to tell for sure which is used as the average period.
W7 and w2k8 machines seem to use DefaultPeriod: render.c:185: Returned periods: 10.0000 ms 3.0000 ms render.c:333: Returned latency: 10.6666 ms render.c:626: event after Start average 10.004ms render.c:2206: event average 9.992ms sigma 0.447
Vista may use its reported StreamLatency as period: render.c:185: Returned periods: 10.0000 ms 3.0000 ms render.c:333: Returned latency: 10.6666 ms render.c:626: event after Start average 10.697ms render.c:2206: event average 10.736ms sigma 0.834
The one w2k8 machine is peculiar as it appears to use the 15.600ms (or 15.625ms?) timers well known from pre-Vista times: render.c:185: Returned periods: 10.0000 ms 3.0000 ms render.c:333: Returned latency: 10.6666 ms render.c:626: event after Start average 15.547ms render.c:2206: event average 15.625ms sigma 5.625
However, the rate is certainly not the 20-30ms StreamLatency that e.g. winealsa returns.
Regards, Jörg Höhle