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

[Paul Davis]

On Thu, 2006-11-30 at 21:52 +0100, Ronald S. Bultje wrote:

> Same for Jack, of course, although Jack came before dmix so it's too easy
> to get away with it so I won't bother (although my opinion stands).

JACK had several goals, one of which was inter-application audio. This
is something still not explicitly addressed by any other API, though
thankfully PulseAudio, GStreamer and others are making it possible to
use JACK for this (and other) purposes.

> So let's sit here for a second and think of why CoreAudio is really such a
> success on OS X. I'd say it is because there is nothing else.
> 
> Really.

I am in 100% agreement. I've been very vocal about this issue. 

However, wishing that we had a similar situation will not make it so. We
are not going to get a single API on linux, probably ever. If we do, it
won't be for a long, long time. Yes, life would much easier if we had
only 1 API, but we don't and we have to deal with that situation.

> we're left with modern systems such as ALSA, jack and PA. Let's leave gst

people disagree over whether ALSA should be included in this. ALSA's
design focuses on being a hardware abstraction layer, and for this, it
is very very good. when you try to use ALSA to do other things (e.g.
route audio between applications), it gets creaky, cranky and sometimes
just can't do the job. end user convenience drops down, way down. 

> And that is the key question here. What API will "Linux", for whatever
> definition of Linux that we give to third-party resellers and application
> developers, offer to those vendors? The only reasonable choice is ALSA. So
> promoting Jack and PA and bla bla bla is really interesting, but it's just
> noise.

i disagree. i was involved very early on in ALSA, helping to design
parts of ALSA 0.6 and then ALSA 0.9 (which later become 1.0). i don't
want to claim much credit - the parts i did were tiny, and i dropped out
of ALSA development as work on alsalib starting ramping up. but i can
say that ALSA was not designed with the goals that PA, JACK, Phonon or
GStreamer have (and even these 4 have different goals).

> > That's the mess I want to see cleaned up. Certainly, it would be nice
> > if suddenly all apps would use ALSA and nothing else

this isn't going to happen. i have a lot of very happy users on OS X,
and will soon have even more on windows. i cannot write for an API that
is tied to linux. many other audio ISV's share this attitude (or would
if someone convinced them to write for linux in the first place).

> > talk directly to the hardware. That was traditionally OK, but nowadays
> > this becomes a problem: you might want to stream its output to other
> > apps. You might want to adjust the volume of each playback stream
> > individually. You might want to reroute audio output from one output
> > device to another one while is playing. You might want to output audio
> > on more than a single device at the same time. You might want to send
> > audio to a different machine on the network. You might want to
> > multicast audio on your net. However, that all is not possible with
> > just ALSA.
> 
> I really just want to play and edit audio, 

i'm sorry, but thats a silly answer. deeply silly. because your current
perception of your needs are limited, you propose that the system-wide
solution should be similarly limited? those people who want to route
audio from xmms/amarok/player-of-the-day through JackRack and then
icecase it are just on the wrong platform? 

i drew up a list of use cases that a "linux desktop media solution" has
to cover post-DAM-1. i can repost it here if you like. ALSA is not
capable of addressing the full list. and even if it did, its not cross
platform. as a "linux desktop media solution" its dead in the water,
even though as a HAL for people writing backends, its really pretty
great.

--p