[PATCH] dsound: Use event based threads

[Maarten Lankhorst]

Op 04-12-12 17:26, Joerg-Cyril.Hoehle at t-systems.com schreef:
> Hi,
>
> Maarten Lankhorst wrote:
>> Alsa's native period is ~ 22ms (1024 samples / 44100 or 48000) with dmix despite claiming it to be otherwise..
> What I don't understand is why you talk about ALSA at this level. DSound talks
> to mmdevapi and that's DSound's underlying API, not ALSA.
>
> So if Wine's mmdevapi claims a 10ms period, it ought to behave like a
> native shared mode driver with a 10ms period.
>
> IOW, I expect 10ms decreases of padding from winealsa when it claims a 10ms period,
> even if dmix/ALSA uses 21.333ms, PA-ALSA uses 50ms or Jack-ALSA uses 150ms.
>
> That means winealsa needs more polish...
>
> I talked about this decoupling between the app <-> mmdevapi <-> ALSA/OSS/XY
> some time ago in wine-devel. I still believe this is less prone to app bugs than to have
> mmdevapi publish the period of 20, 50 or 150ms of its back-end, because no native app
> was ever tested with such periods. MS apps are not prepared for them.
[Citation needed]

Now if you were talking about the IAudioClock, and preferably have some good tests that fail with current winepulse, I would believe you.
> If you think that's not a good path to go, please raise your voice.
VERY LOUDLY!
> (Some may argue that winecoreaudio has been using 20ms since day 1, not 10ms. Maybe that's close enough.
>  OTOH, I've mentioned today that my Mac machine stutters at the render test,
>  so wineCoreAudio is not yet in its best shape).
I haven't looked at winecoreaudio at all.

>
>> GetStreamLatency is also used for calculating the period size, see
> http://msdn.microsoft.com/en-us/library/windows/desktop/dd370874%28v=vs.85%29.aspx
> "clients can use this latency value to compute the minimum amount of data
>  that they can write during any single processing pass."
> That one paragraph is indeed interesting. I have no explanation of it yet.
> What's true is that 10ms won't get you far when the back-end's period is 20, 50 or 150ms.
> However, I was talking about a continuous supply of 10ms chunks.
>
> (We are already past the ancient bug that "ALSA/dmix won't start if not fed at
>  least one ALSA period full of samples" - imagine the period were 150ms.)
Or it sometimes refuses to flush the last remainder for writing.. if it's less than 1 period.

>
>> I don't think it's used as such in this commit yet, but in the mixer
>> rework it's used it to calculate fragment length.
> I'm not familiar with DSound. For sure, GetStreamLatency
> should be involved in buffer size calculations, e.g. as a lower limit.
Indeed! :D

>>> have dsound call into the system openal to perform multichannel mixing and 3D processing. (...)
>> ... Must print this out on poster format, and frame this above my bed..
> This must sound like going a full circle to you. Wasn't some earlier version of DSound and/or mmdevapi
> based on OpenAL until some devs concluded that it was not a viable path?
>
>
>> Except WAIT_OBJECT_0 is defined as 0.
> I don't want to remember that.
>
You're now never going to forget that WaitForSingleObject and WaitForMultipleObjects with any=true returns the index of the first waited on event. ;-)

~Maarten