[PATCH 5/6] dsound: rework ugly mixer logic
Joerg-Cyril.Hoehle at t-systems.com
Joerg-Cyril.Hoehle at t-systems.com
Wed Oct 24 05:36:20 CDT 2012
Maarten Lankhorst wrote:
>only oss4 and (maybe, just guessing?) coreaudio don't support float
MacOS' CoreAudio supports floats. Actually, given that it's an entire
audio pipeline like quartz, I bet it even prefers floats.
>I also refer you to GetStreamLatency where I was getting the period from,
>Please take it from me: IT'S OK TO FAIL THOSE MMDEVAPI PERIOD TESTS,
I agree that some tests are extremely strict and that a "good enough"
driver could work extremely well in practice despite failing some
tests. However, please specify exactly which tests you have in mind so
that we all talk about the same set.
>BUT PLEASE DON'T LIE ABOUT THE HARDWARE CAPABILITIES REGARDING
>TO MINIMUM PERIOD, DEFAULT PERIOD AND STREAM LATENCY.
The reasoning is as follows: First, tests show that native exhibits a
10ms period, hence we can assume that every PC SW has been tested with
that period only. Using another period in Wine might reveal bugs in
the apps, but users would blame Wine.
This is why I've been arguing no later than last week in bug #28622,
comment #58 that Wine should fully decouple ALSA/OSS periods from the
published 10ms mmdevapi periods.
OTOH, winecoreaudio has been using 20ms periods since day 1 in 2011.
I'm not aware of bugs in bugzilla caused by that deviation.
Second, the shared mode audio engine IMHO presents an abstraction over
any particular HW, providing the same behviour on all machines and
eliminating the need for app X to talk to or work around bugs in sound
driver Y. Thus I wonder why you talk about hardware capabilities at
all. IOW the shared mode caps are: fixed period=10ms and unlimited
buffer (MSDN says 2s).
a) Minimum Period
Why do you care? It's only relevant in exclusive mode.
I'd say that minimum = shared mode default period is a reasonable
value. And if default=10ms, minimum = 5ms seems ok if it has been
tested and works well. OTOH, 200 periods and wakeups per second may
be unrealistic as we alreadty struggle to sustain 100.
Do you know an app that uses mmdevapi in exclusive mode?
b) Default Period == shared mode audio engin period
The target is 10ms, see above.
Yet we could make exemptions: for instance, we might observe that all
apps using mmdevapi use it via the XAudio2 libraries and that XA2 is
well debugged and would bear a larger period, e.g. 50ms.
There should be a registry setting for users to play with.
I'm not happy with Wine's DSound+WinMM->mmdevapi. That may be a good
move for MS, but it's a bad move for Wine. Wine's audio drivers don't
bang the HW, they have huge SW stacks like PA or Jack in their back.
c) Stream Latency
Bear in mind that the mmdevapi stream latency is a static property of
an audio SW transformation graph. It does not vary if some buffer is
full or empty. It is unlike snd_pcm_delay.
I believe winealsa outputs a reasonable stream latency. One may argue
that it is too low: as winealsa always buffers 3 periods
internally the latency should count those. I kept it low because
native's mmdevapi is reported to introduce 30-40ms delays yet its
GetStreamLatency ignores that and reports values like 10.6666ms.
Perhaps we are wrong about GetStreamLatency. Perhaps it's always a
local call to one element of the audio transformation graph and should
never sum other elements itself. Perhaps the app should use some
enumeration facility to walk the audio graph and sum each element's
latency? Perhaps there's some native graph element that would report
said 30-40ms latency?
More information about the wine-devel