Op 21-12-12 11:59, joerg-cyril.hoe...@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