dsound: use event based threads, v2

[Joerg-Cyril.Hoehle at t-systems.com]

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