brainstorm: what are the audio stumbling blocks?

[Maarten Lankhorst]

Op 26-01-12 12:59, Joerg-Cyril.Hoehle at 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