Op 21-12-12 11:59, Joerg-Cyril.Hoehle@t-systems.com schreef:
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.
<snip>
Because I'm using it later on in the rework to tell how much to queue. In my rework, I try to write at most 3 * GetStreamLatency, so even if for some reason no event is ever delivered, you would never get an underrun.
This is why I choose streamlatency instead of getdeviceperiod. Also since it may be a different value, who says it's only going to be bigger than the default period? It could theoretically be smaller, still..
~Maarten