[PATCH] dsound: Use event based threads
maarten.lankhorst at canonical.com
Mon Dec 10 02:23:07 CST 2012
Op 04-12-12 17:26, Joerg-Cyril.Hoehle at t-systems.com schreef:
> 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.
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.
> (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
> "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.
>>> 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. ;-)
More information about the wine-devel