Op 26-01-12 12:59, joerg-cyril.hoe...@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/431e943193d0d916a7bb6be32b0c20a432854474
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
