Op 26-01-12 12:59, Joerg-Cyril.Hoehle@t-systems.com schreef:
Hi,
What are the areas that would have the most impact if fixed? You are invited to participate and share your thoughts.
I believe we need to distinguish winmm/dsound/mmdevapi/OS.
mmdevapi:
A. lock-less timer callback design, bug #. But I don't think where we would get the most improvement from avoiding a few EnterCriticalSection.
B. Stability of time base, bug #. Perhaps major. My render "worst case" test showed that CreateTimerQueue never invoked callbacks every 10ms as asked rather than 8 or 12ms. I don't know if that's the Linux jiffies we see here.
C. too small ALSA buffer for the backend I've sketched a "hidden frames" design that would allow using a larger ALSA or OSS buffer, but that needs a reliable estimate of how much ALSA has buffered. Also, that's at odds with DSound and XAudio2 which want short latency and presumably don't send much data in advance.
Every audio HW guy recommends using audio buffers as large as possible. Can't we just because of the f**ing 10ms period?
Sorry, we don't control delivery, and can't tell applications how to behave... Just bite the bullet and add a winepulse driver already, I'll even fix mine to work better if it had a chance of getting accepted, not having a driver for the default linux audio system is just silly..
D. timer frequency Is it really important to match native's 10ms period? The UNIX world is trying to decrease the number of interrupts in order to preserve battery life, but we go backwards and move from a model which dynamically computed the next wake-up based on the number of submitted frames to a tiny fixed period. Are we crazy?
E. lead-in aka. "ALSA won't start", bug #
F. lead-out aka. finish playing trailing frames not modulo period size, bug #
G. other mmdevapi
winmm:
H. GetPosition is not (yet) == mmdevapi's GetPosition
I. other winmm
DSound:
J. time base? It uses timeSetEvent. What if using mmdevapi's event?
K. buffer size too small or not matching whatever needs?
L. issues with GetCurrentPadding/GetPosition The "true position" may be too far away from the write pointer, e.g. PA's typical 2s latency. Deal with that, matching DSound's and the apps' expectations as well as Linux/BSD/OSX sound systems.
See V.
M. DSound's underlying model is a ring buffer. This does not match mmdevapi's. Should we bypass mmdevapi because all it adds is latency? Reinvent HW acceleration? Provide a hidden API in mmdevapi?
No need, you know how mmdevapi behaves, you can write it in such a way without adding latency by using GetCurrentPadding or the clock.
N. other DSound
XAudio2: Modern apps will use that because mmdevapi is too low-level, presumably DSound usage will decrease.
O. XAudio2 appears to use the "worst case small period size writes" known from the Rage bug #
P. other
Capture:
Q. whatever capture issues
UNIX host:
R. thread priority -- no "Pro Audio" / Real-Time priority
Not going to happen, ever. AJ nuked all my attempts at it,
dbus+rtkit watchdog version is here: http://repo.or.cz/w/wine/multimedia.git/commit/431e943193d0d916a7bb6be32b0c2...
S. reliability of event/interrupt delivery over sustained intervals (hours, not minutes).
...?
T. Wine SetEvent& server round-trip times
This is indeed an awful case, but with the wineserver designed the way it is there's no other way around it, I honestly wouldn't be surprised if this is a performance issue on its own for some games...
Other:
U. FMOD& whatever, any particular constraints?
Last I checked (ages ago) fmod just worked. Might be different since last rewrite though..
V. other?
(rant in general) Stop trying to support pulseaudio with winealsa, with all the efforts you would have had a fully functioning driver by now. See my tree for a start, but it doesn't appear to work in extremely low latency cases (winepulse -> pulseaudio -> jack with jack set up for 40 * 3 samples buffer), need to look at it more first.
Thanks for your contribution, Jörg Höhle
~Maarten