brainstorm: what are the audio stumbling blocks?

[Joerg-Cyril.Hoehle at t-systems.com]

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?

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.

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?

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

S. reliability of event/interrupt delivery over sustained intervals (hours, not minutes).

T. Wine SetEvent & server round-trip times

Other:

U. FMOD & whatever, any particular constraints?

V. other?

Thanks for your contribution,
 Jörg Höhle