[gst-devel] Linux audio is a mess? [was: JACK and GStreamer, from the horse's mouth]

[Paul Davis]

On Wed, 2006-11-29 at 17:31 +0100, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, 29 Nov 2006, Paul Davis wrote:
> > The ALSA API supports push and pull models.
> [..]
> > dmix is very, very clever. that doesn't mean its necessarily the right
> > solution. the internals (kernel-side) of CoreAudio are another
> > interesting approach to the same problem.
> 
> So, then could anyone explain to me how using jack or pulseaudio instead
> of improving dmix to, for ex., be better in pull-environments would be
> good to my good friend Joe A. User? Imagine how many applications you
> suddenly don't have to adapt to support your cool new soundsystem, because
> - hey! - they all already support ALSA.

suppose Joe A. User wants to use a VOIP application, but wants to record
the conversation, or wants to play back a new piece of music as part of
the call. if the VOIP was part of an inter-application audio routing
system, this becomes trivial to do. but there are basically no VOIP apps
that (a) use JACK (b) are written in a style that make them amenable to
inter-application audio routing.

of course, most of the time, Joe A. User doesn't want to do this, and
just wants their app to run by itself, without JACK. so now, the app
developer has to handle two different backends. what is the developer to
do? the worst approach, of course, is for them to try to build
everything into their VOIP app. 

in theory, ALSA's alsalib can handle all of this. its possible to set up
JACK as the default PCM destination, for example, so that every app
actually writes to JACK. the problem is that the level of functionality
required for this to work properly has been a long time coming, and
people have used other things. there is also the issue that lots of
developers want to write apps that port to OS X (and possibly windows)
so it becomes necessary to not have to redesign the entire data flow
through the application when doing so. the simplest basic design to make
this work is a pull model, since pull APIs are in common or sole use on
these platforms. net result: developers don't want to use ALSA because
(a) it didn't use to be capable of doing many things (b) it is still not
capable of be the basis of or a solid partner in full-fledged
inter-application audio routing and (c) it is not portable to other
platforms.

when ALSA was being written (and i was there), the main focus of the
design effort was of a nature that calling ALSA a "HAL" is more accurate
than calling it an audio API. alsalib received much less effort than the
device drivers did for many years, and by the time anyone was even
thinking about inter-application audio routing, JACK already existed.
ideally, we should have done JACK as part of ALSA, but hey ... because
we didn't, JACK now offers its services to OS X and Windows users as
well, providing a common API for pro-audio/low latency apps on every
platform. as far as tradeoffs go, i think we made the right choice.

> I just can't get my head around that RedHat would pay people to work on
> something this stupid, unless it is purely to annoy Novell.

they don't. monty is working on something rather different.