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.
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).
GetStreamLatency is also used for calculating the period size, see
http://msdn.microsoft.com/en-us/library/windows/desktop/dd370874%28v=vs.85%2... "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.)
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.
Regards, Jörg Höhle