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

[Lennart Poettering]

On Thu, 30.11.06 21:52, Ronald S. Bultje (rbultje at ronald.bitfreak.net) wrote:

> On Thu, 30 Nov 2006, Lennart Poettering wrote:
> > In a way, PA is just a way to fix "dmix". PA can be started on-demand
> > from libasound, which makes it behave much like dmix, a very powerful
> > dmix.
> 
> I'm aware that both PA and Jack can be used in that way. That leads to the
> following questions:

> - why is there a separate API? Why is it being pushed?

Hey, wake up!

Please read other people's emails carefully before responding to
them. If you'd have done that you would have noticed that I am not
pushing the PA API. I am not even convinced that our current API is
such a good design, at this point.

I love to quote myself:

<snip>
 In PulseAudio we currently have an API which tries to find a
 middle ground between the pull model and the open/read/write/close
 model, one that blurs the lines between both models. While this is a
 very, very powerful API it is also a very complicated API. And in my
 eyes, it is too complicated and bulky. That's why we currently do not
 recommend anyone to make use of our API. I am little uncertain how to
 pursue the quest for a stable API for PulseAudio. Right now my
 position is this: there is no perfect API, just a bunch of accepted
 APIs we can be compatible with. Right now these are the ALSA, OSS and
 maybe libao.
</snip>

So, while this quotation tells you that we're not actively pushing for
adoption of this API, your question why we need that seperate API
still stands unanswered. So: the ALSA API has been designed with
hardware devices in mind. Unfortunately this doesn't map that well to
networked audio servers. A few of the problems we have with the
current ALSA API: 

1. our latency estimation model cannot be exported cleanly through it,
the extra latency that is added through the network cannot really be
passed to the user.

2. our buffering model (which besides other cool stuff allows free
seeking) is vastly different from the usual fifo hardware buffers. Our
buffering is very powerful and useful when you do playback over a
network, but this simply cannot be exported in the ALSA model
correctly.

3. Our mixer interface cannot be mapped to the ALSA interface in a
clean way.

4. Our API allows introspection/module loading and lots of extra stuff
that is specific to PA and cannot and should not be exported through
the ALSA API. 

5. Stuff like naming streams after the song title is not available
with the ALSA API, but is in the PA API. Our plugin for GStreamer, as
an example, renames the playback stream after the song title. 

6. While the PA API is fully asynchronous, the ALSA API is fully
synchronous. This creates a few problems.

7. ALSA doesn't offer an API for sample cacheing, something which is
crucial for thin clients.

And there's probably more.

Most of these issues can be worked around. But these work-arounds are
not exactly the cleanest things of the world.

> - why isn't PA as dmix-replacement in ALSA pushed much louder?

C'mon. This question is just stupid.

Why isn't GStreamer pushed much louder as media layer for KDE? I mean,
they didn't take it, hence it wasn't pushed loud enough, right? 

> And directly following from that:
> - why was PA developed, and didn't you just fix dmix?

As I said: *in a way it can be seen* as dmix replacement. However, it is
so much more. And to be that it needs a completely different
architecture.

You're question is like "Why was vi developed, and didn't they
just fix ed?". It's just ridiculous.

> 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).

BTW: PA predates dmix as well - in a way.

> > ALSA is not "the solution" for all problems we currently have in Linux
> > multimedia. Why? Because it doesn't provide compatibility with OSS,
> > with ESD and what not. It's just one API. And there are others, which
> > are unlikely to go away, which however are incompatible with
> > ALSA.
> 
> Right, and you fix that by introducing Yet Another Linux Audio API
> [tm].

Hey. Firstly, I am not pushing a PA API. Secondly, let's quote myself
once again:

<snip>
It's not clear to me what the OSDL tries to achieve with the DAM
multimedia meetings? Is the plan to define a new abstracted sound API?
That would be a very difficult thing - and a very questionable one as
well - since there are so many APIs around already.
</snip>

That sounds very critical of introducing yet another linux audio API
to me, doesn't it to you?

> 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.

You're mixing all things up. Noone is proposing JACK or PA as *the*
Linux multimedia APIs. 

> > 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, and because we don't have the
> tyrranny of a single sound system pushed upon us, whether we like it or
> not, I'm not able to do so because some apps require Jack, some require
> gstreamer, some talk to esd and some are still OSS-only and my soundcard
> can't mix in hardware.
> 
> And PA doesn't fix that. If you think about it, it just makes it
> worse.

Oh, it doesn't fix "that"? Let's see:

* PA has a plugin for libasound: check!
* PA has a very good gst driver: check!
* PA has a compatibility layer for ESD: check!
* PA has the best OSS compatibility around and through FUSD it will
  get near perfect compat: check!
* PA can run in conjunction with JACK: check!

OMG! PA *does* fix "that"! 

(Admittedly, the JACK integration is not that great right now. It's
more a proof-of-concept, than something you really want to work with.
It is my intention to integrate PA with JACK in a better way,
eventually. However, we're only human, so we cannot provide you with
all you're dreaming of already yesterday.)

> PA is great, and integrating relevant parts of it inside ALSA (either in
> dmix or in a PA-based dmix replacement) would make this a lot better. How
> about that?

Hmm? The pulse plugin for libasound is shipped with upstream ALSA, and
has been so for quite a while now. So "relevant parts" are already
inside the ALSA project. How about that?

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/