LWN: Comments on "LPC: Linux audio: it's a mess"

LPC: Linux audio: it's a mess

jcm — Tue, 08 Dec 2009 07:51:10 +0000

Most desktop users (in my personal opinion) couldn't give a rat's ass about controlling the volume of individual apps or doing remote streaming. I can do both on this system and I have used them (on this system) precisely...never. It's just not even a big deal.

We now seem to be headed done some "let's all become Macs" road in which configuration is removed to benefit perceived needs of desktop users (mixer settings going away in rewrites when a simple "advanced mode" toggle would have sufficed) who aren't going to use the per-app. volume settings anyway.

I don't hate PA, I just find it gets in my way. Every time I upgrade my desktop or laptop, something audio breaks or changes behavior in an undesirable fashion.

Jon.

ALSA safe subset

pharm — Mon, 29 Jun 2009 16:23:05 +0000

Just in case this pops up in Google searches:

ALSA safe subset documentation, amongst other things:

http://0pointer.de/blog/projects/guide-to-sound-apis

LPC: Linux audio: it's a mess

nix — Sun, 05 Oct 2008 17:29:23 +0000

It's not that you're bashing Lennart, it's more that you're basing your
bashing on content-free innuendo. *Why* doesn't network-capability belong
in 'the mass of machines'? Why does the pulseaudio native network protocol
*plugin* 'introduce[] bugs and eat[] memory and cpu'? Got any evidence? I
doubt it, because there is none. (I mean, yes, obviously deserializing
data flowing over the network costs a bit of CPU time, but it's utterly
insignificant, and you don't even pay that cost unless you're doing
network streaming.)

I don't even know what your criteria for measuring 'performance' are,
given that your examples are matched by pulseaudio (given hardware that
supports hi-res timers, at least).

Personally I use Pulseaudio for one reason: *API compatibility*.
Pulseaudio can emulate virtually everything (other than Jack) so I don't
need to run a mass of battling incompatible sound daemons anymore: I can
just run one. (And yes, it *can* mix stuff from multiple sources and sinks
freely.)

The rest of your post is sub-Slashdot ad hominems that aren't worth
responding to.

LPC: Linux audio: it's a mess

Joes — Sun, 05 Oct 2008 14:57:22 +0000

Why pulse is not ready for prime time, and probably never will be.

A network capable sound daemon does not belong in the mass of machines that have sound cards. This just introduces bugs and eats memory and cpu.

A configured audio stations with Jack and ALSA outperform pulse in every instance.
Separate volume controls
No glitches in sound
Multiple apps recording and playing simultaneously

Plus Low latency!

Every now and then a bad idea like this gets more marketing than engineering.
Just look at mono. hmmm...
Mono gets you a job with microsoft.
Pulse gets you a job with redhat.

Now I understand why it was written.
Pulse programmers may be skilled but there's been many a skilled programmer that has written "great" code that causes more problems that it solves and like mono, encourages others to go down a bad path.

And if you take offense that I'm bashing pulse programmers, well I now have to spend a half hour or more every time I install Fedora, SUSE, Mandriva or Ubuntu to get decent sound working. That wasn't the case before pulse got shoved into the distros prematurely.

Disable Flash in the Browser

alex — Thu, 25 Sep 2008 13:12:10 +0000

Install both and then disable one with Tools/Add-ons/Plugins in Firefox 3?

LPC: Linux audio: it's a mess

graydon — Thu, 25 Sep 2008 05:04:47 +0000

I'd wager most of us non-sound-expert users just want a single volume control that makes sound louder or quieter, that we can always find, and that always works. No mysteriously silent apps, and no configuration save for the volume buttons physically on the computer.

For as long as I can remember, linux has over-engineered and under-delivered audio. It'd be a pleasant surprise to change that habit. But I'm not holding my breath.

way [OT], but...

roelofs — Thu, 25 Sep 2008 02:46:15 +0000

jmspeex

Obscure Babylon 5 reference?

Greg

LPC: Linux audio: it's a mess

mezcalero — Wed, 24 Sep 2008 20:56:01 +0000

At Plumbers one thing became very clear: someone needed to sit down and write up a guide through the jungle of Linux Audio APIs because we have so many and so many are incompatible. And so I did it:

http://0pointer.de/blog/projects/guide-to-sound-apis.html

laptop and desktop

mezcalero — Tue, 23 Sep 2008 20:07:41 +0000

I am happy to merge patches for that.

laptop and desktop

foom — Tue, 23 Sep 2008 14:52:20 +0000

Sad to hear that about the patents...but is there really any issue with using an AC3 encoder/decoder library if the user happens to have one installed already? (maybe they've already paid the licensing fee to Dolby, e.g. through buying a Dell with Ubuntu preinstalled).

laptop and desktop

mezcalero — Tue, 23 Sep 2008 13:45:06 +0000

PA focuses on PCM right now. Support for pass-thru codecs is on our TODO list.

However, please note that we will probably never support on-the-fly AC3 decoding or encoding due to patents.

Lennart

LPC: Linux audio: it's a mess

mezcalero — Tue, 23 Sep 2008 13:42:09 +0000

The list of ALSA issues I maintain still exists and is regularly updated:

http://pulseaudio.org/wiki/AlsaIssues

Lennart

LPC: Linux audio: it's a mess

fergal — Tue, 23 Sep 2008 09:09:31 +0000

Seems to me that everything is a file doesn't have to mean that everything is a single file. You don't have to represent your whole soundcard via a single file. Think of /proc or /sys.

The problem is it is quite difficult for a program to present itself as a coherent set of files. While it can easily enough produce a file-like interface, it cannot easily produce a directory-like interface.

ALSA safe subset

sdalley — Tue, 23 Sep 2008 08:57:53 +0000

Is this safe subset of ALSA documented as such anywhere? If so, we need as many people as possible to BANG A REALLY BIG DRUM about it/write a beautiful Programmers Guide about it/write love songs in it, so that Linux sound applications everywhere can start getting things right now and not break/have to be ported again when libsydney comes along.

+1 for no userspace daemon

lysse — Tue, 23 Sep 2008 06:35:43 +0000

That just shows that the two models are equivalent in expressive power, like inheritance and delegation. If we couldn't synthesise one from the other, JACK couldn't exist - but it'd still be nicest of all to have both available at the lowest level :)

LPC: Linux audio: it's a mess

angelortega — Tue, 23 Sep 2008 06:09:00 +0000

Programmers use OSS and not ALSA because the OSS API is *much* easier to
use than the ALSA library mess.

Also, regarding libsydney, creating yet another wrapper library is not the
solution. If you try to fix the problem of having 3 competing parts by
adding another one, you end up with 4 competing parts and no solution.

laptop and desktop

foom — Tue, 23 Sep 2008 05:04:21 +0000

> Uh? PA supports surround sound just fine. Even does automatic upmixing/downmixing
> from/to stereo for you.

Sure, but doesn't transparently support the most common source/sink of surround sound: AC3
DVD audio to AC3 over SPDIF output.

If PA automatically supported AC3 encoding of surround sound to my SPDIF output, without
having to manually configure an external encoder program, that'd be good.

If PA could allow routing of AC3 audio through to the SPDIF port without the decoding/encoding
overhead and resultant quality degredation, that'd be great.

But, if it could do that, *and* transparently fall-over to doing a decode/mix/encode when it
needs to mix another stream into the output (e.g. an alert sound or what have you), it would be
an absolutely amazing achievement: that's something that you just can't do today. And I'd really
like to be able to do that.

Also, volume control is an interesting trick when not decoding the ac3 stream locally; I dunno
much about it, but I'm led to understand there's some metadata in the frames which can be set to
affect the volume on the decoder. Maybe (hand-wave) that could be modified in-flight without
re-encoding the stream. :) If PA could do that, that'd be even another advantage over the
existing ALSA solution.

One can always dream...

Thank you

jebba — Tue, 23 Sep 2008 00:46:20 +0000

"Is that a distro optimized for minimal battery lifetime of your Eeepc?"

There are two FREEEEE modes[1]: full-on media and low power ebook.

With jack, multiple mplayers, freej, firefox, chat, xournal, an offline copy of wikipedia, an image viewer, wifi, camera, etc all running it runs hot, yes. :) But it also runs all that fine without dropouts or crashing. jack performs reliably *now* and is never the weak link. Occasionally I have used pulseaudio as a jack client, which is convenient, but it is no where near as reliable as jack.

jack is clean, "feels" like a nice unix utility (it does its "one thing" extremely well), and has a committed upstream community.

-Jeff

[1]Second mode yet to be completed :)

+1 for no userspace daemon

nix — Mon, 22 Sep 2008 23:22:44 +0000

A 'stream/callback interface' can be modelled as a pair of files, one of
which is a source of data and one a sink, or as a single file which you
can read() responses from as you write() stuff to it. Anything you can do
with a TCP/IP socket you can do with a suitably backed file, and we know
very well that you can define protocols over network sockets :)

LPC: Linux audio: it's a mess

nix — Mon, 22 Sep 2008 23:21:23 +0000

I'll add you to my extensive and elaborate statistical baseline (from
which data is extracted using gut feelings and rand()).

+1 for no userspace daemon

lysse — Mon, 22 Sep 2008 22:12:50 +0000

Same here... with the possible exception of jack - but even then, I can't help but wonder whether the Unix "everything is an entirely passive file" is quite the thing for audio. No problem at all with "everything is a file", but why not say "every file can be opened with either a passive interface or a stream/callback interface"? Wouldn't make much difference for files which are blocks of disk, true, which is why having both is nice - but the stream/callback paradigm is more or less perfect for pipes; after all, it's more or less how they work anyway... and since that's the model jackd presents to its applications, wouldn't the need for it would more or less go away altogether?

LPC: Linux audio: it's a mess

lysse — Mon, 22 Sep 2008 22:06:28 +0000

...by introducing yet another library...? I can see a flaw in that :)

LPC: Linux audio: it's a mess

lysse — Mon, 22 Sep 2008 21:49:59 +0000

I don't care. Do I get to be a data point?

LPC: Linux audio: it's a mess

nix — Mon, 22 Sep 2008 20:57:51 +0000

Note that I'm not saying OH NOEZ PA SUCKS COS EVERYTHING IS NOT A FILE or
even 'oh no you must rewrite PA so that everything is a file'.

I'm just wishing for an ideal world in which the Unix philosophy was still
as universally followed as it was in its early days, and musing about ways
to make that happen. I think a working revoke() is the biggest missing
piece (and libraries to make exposing one's configuration state as a FUSE
filesystem painless).

LPC: Linux audio: it's a mess

nix — Mon, 22 Sep 2008 20:46:01 +0000

ioctl() is awful, everyone agrees. It's not virtualizable, it's not 32/64
compatible, it's not typesafe (as you said), it's thoroughly opaque...

The way to structure this is to put your controls in a directory, or a set
of directories, one file per control, rather than using ioctl() on a
single file with different requests. The way you solve the 'remove this
user' is to create these directories on the fly, and zap their contents
when the user logs out: even if the user retains a handle to the
directory, it's empty now so they can do nothing with it. (You might need
a simple non-device revoke() to do this properly, such that all I/O to an
ex-session fd returns -EIO, but this has already been written: it just
hasn't been applied because it's difficult to make it work with things
like PTYs. For this application, we don't care about that at all). Plan 9
did all this two *decades* ago and got it right: why can't Linux do it
now?

It's not even hard to make a system that works like this in userspace,
thanks to FUSE.

LPC: Linux audio: it's a mess

tialaramex — Mon, 22 Sep 2008 18:19:30 +0000

The conclusion that you'd spent a lot of time moaning about ALSA was based on reading ALSA's archives in the past and on observing that there is (was?) a lengthy list of alleged problems in ALSA on your PulseAudio site. As far as I know I've never met you in person, and so I have no opinions about you except as a software developer.

ALSA isn't perfect, that's true, I have several enhancement bugs open and I've had discussions with ALSA people about various aspects -- notably I wanted a way to determine which ALSA level ("volume") control, if any, is the most appropriate to tweak for a PCM stream I have open, thus making it possible to make good use of a hardware PCM stream mixer as provided in say an SBLive. The kernel drivers are also not perfect, the driver for my Intel chipset can't properly handle a running audio output during suspend for example. But PulseAudio doesn't (and shouldn't try to) fix that problem.

I am a JACK user, so I am not, as you seem to assume, wedded to ALSA as the solution to all problems. I do think that you underestimated how mature PulseAudio needed to be before it was a better option than the default dmix configuration present in e.g. Fedora prior to PulseAudio. Not so long ago I encountered an old friend who happens to be a Google engineer (I say this only to establish that he's a smart get-things-done guy) who'd basically given up using audio on his laptop because he upgraded Fedora and that installed PulseAudio and broke the sound. PulseAudio's promise is good, but as of the last version I tried (was forced to try) it doesn't deliver that promise for a lot of people yet.

I remain to be convinced about PulseAudio. But don't imagine that I can't be convinced. I wasn't very impressed with early versions of NetworkManager either, but it got better. Probably I'd be less soured on PulseAudio if it had been in Fedora as an optional extra, to get feedback from people who know what they're getting into and perhaps have good use cases (e.g. hotplugging audio devices).

LPC: Linux audio: it's a mess

drag — Mon, 22 Sep 2008 17:09:21 +0000

Jack is solving a different problem domain. There is very very significant differences and requirements between people wanting to do real time audio editing vs multimedia playback.

Plus it's possible to play regular applications through PA and into Jack, if you want to use a familiar application or media source.

> Still, a good start would be a aggressive purge of legacy solutions - arts, esd, mas, various parts of libalsa.

Ya. Unfortunately that requires rewriting applications that depend heavily on those API.

For very modern-style applications that use things like Phonon or Gstreamer, this shouldn't be a big problem since those things are designed to be modular. Arts is being taken care of through the KDE folks, who are forced to rewrite their applications to work with QT4 anyways. Mas isn't popular. PA is compatible with Esd.

Then there is OpenAL, SDL, and numerous other much more minor sound APIs.

LPC: Linux audio: it's a mess

drag — Mon, 22 Sep 2008 16:55:41 +0000

> Sometimes you want the same thing in multiple places to help usability.

Not when those multiple things do very different and conflicting actions in very very non-obvious manners.

If you have:
1. Mozilla Browser volume control and mute.
2. Gnome Volume Control and mute (that ties into your volume icon and multimedia buttons)
4. Low-level Alsa volume control and mute.
5. Speaker volume control and power.

Now you open up a youtube video. You get no audio.

Tell me, with certainty, which control, or combinations of controls, you will have to use to make the sound audible.

There is a difference between having 3-5 different places to control volume vs having 3-5 different controls you have to use.

LPC: Linux audio: it's a mess

nhippi — Mon, 22 Sep 2008 13:23:08 +0000

That's ignoring at least phonon and jack, that will continue to exist. Also, how does libsydney fall in? And the embedded people will have openmax...

Still, a good start would be a aggressive purge of legacy solutions - arts, esd, mas, various parts of libalsa.

LPC: Linux audio: it's a mess

mezcalero — Mon, 22 Sep 2008 11:03:39 +0000

ALSA is an API for hardware devices. That's root to a lot of problems you encounter when using the PA plugin for libasound. There are certain differences between hardware and virtual devices. Timing works differently, memory management as well.

The devil lies in the details. It's a lot of small issues that make compat difficult. In addition, some fundamental parts, like the reliance on the classic period-based playback model is a weakness that libsydney does not expose. Not exposing periods will greatly increase compat with glitch-free and with network setups. Finally, libsydney allows clients to set all kinds of properties for a stream that make it especially useful for desktop sound servers. (i.e. setting icons for a stream, and so on...)

But there are more things.

Lennart

LPC: Linux audio: it's a mess

mezcalero — Mon, 22 Sep 2008 10:55:13 +0000

So, you want to have an API that follows everything-is-a-file and then not use ioctl()s for configuration of the sound device? How else would you would like to see that happen?

ALSA internally doesn't even use read()/write() anymore. It uses ioctl()s everywhere as a generic function call multiplexer. That we have to do this is due to the everything-is-a-file philosophy and is basically just a hack: you lose type-safety and everything.

Unix access control is too simple: we want that access follows the user that is logged in on the local VT: when he logs out he needs to be removed from the access. Unix doesn't allow that, because if someone gained access he can keep things open as long as hew wants.

I know that e-i-a-f is one of the core fundamentals of Unix. But you know what? It's also one of the core weaknesses of Unix.

LPC: Linux audio: it's a mess

alankila — Mon, 22 Sep 2008 10:26:01 +0000

One thing missing from this discussion is a piece of gratitude: I think Pulseaudio at least is on the right track in that it makes it simple to produce output.

With ALSA, you write this 100+ lines long method with about a dozen calls, each which can fail, some which are necessary before other calls in the sequence will work. It is strangely low level, maddeningly flexible, and poorly documented, so it's very difficult to know what you should do.

At least these questions may arise: What is the sufficient condition to get the output mode that is exact to the spec that you requested? Are there format conversions or resampling in the output path? If resampling, where do I set a reasonable algorithm, as pick-nearest or linear interpolation is not acceptable for audio work? What is the minimal program that produces output and yet has some specified latency? How do you write a working full duplex program?

LPC: Linux audio: it's a mess

hppnq — Mon, 22 Sep 2008 10:07:10 +0000

It is very confusing to the user to find his way through this jungle and figure out which one is the one that is responsible for the low volume of the output.

Considering that this argument is more or less the same as the one in favour of per-app volume controls, one would be inclined to think of a protocol as a solution for this kind of confusion. But it seems like this has already been patented. Sigh.

LPC: Linux audio: it's a mess

ceplm — Mon, 22 Sep 2008 08:16:02 +0000

No, it's Ubuntu which did not make sure, that flash works.

LPC: Linux audio: it's a mess

ceplm — Mon, 22 Sep 2008 08:05:11 +0000

I thought so too, but now I am switching between USB headphones and loudspeakers all the time. Thanks PA!

LPC: Linux audio: it's a mess

NAR — Mon, 22 Sep 2008 07:41:00 +0000

But the people to blame for that are not us, it's Adobe. Please point your fingers in the right direction when you complain!

From the developer's point of view, you're right. From the user's point of view, you're wrong. Youtube used to work with Ubuntu Gutsy (I don't know about your browser, but it doesn't crash mine), doesn't work anymore after the Hardy upgrade (which introduced PulseAudio), so it's obviously PulseAudio is the one that broke my user experience.

Thank you

alankila — Mon, 22 Sep 2008 07:24:35 +0000

In fact with my brief tussle with JACK a year or two back, it seemed to me that the JACK itself might not actually mandate any particular sampling format. It's just that everybody talks float by default, because it is an excellent choice for professional audio work. (If there are any intents to support any other format, they aren't readily apparent.)

The buffers passed between applications were still void * pointers and the only clue for their contents was a simple string describing what kind of format you had requested from JACK, a #define which expanded to a string such as "32-bit pcm floating point audio"...

clue, meet literfizzer

nix — Mon, 22 Sep 2008 07:10:11 +0000

Glitch-free for *everyone*, except those for whom PA refuses to talk to
ALSA (*waves*) or refuses to use the high-def timers that definitely exist
(*waves*).

I really must diagnose this, but trying to find bugs in ALSA's kernel
component is like trying to shovel sewage with a toothbrush. Its
kernel/user interfaces are horrible (and most of both components is
entirely undocumented as far as I can tell: I still have no clue what the
Lisp interpreter is doing in there, for instance. Maybe the docs are just
hiding. Maybe they appeared since the last time I looked at this a couple
of months ago. But, y'know, life's too short: PA mostly works for me now,
and hardly ever glitches even with glitch-free mostly turned off by the
enforced usage of the OSS compatibility layer.)

LPC: Linux audio: it's a mess

nix — Mon, 22 Sep 2008 07:05:06 +0000

I don't seen any incompatibility. The thing behind the file need not be a
raw sound device: it can be another abstraction. OSS's interface sucks,
but that was in large part because it relied on things like ioctl() and
mmap() that just can't be usefully virtualized (as you know much better
than me).

Just select() alone makes fds-for-everything a useful philosophy. I have
no *clue* why you imagine that 'modern things' require splintering a
single consistent interfaces into a mass of incompatible and
non-interoperable interfaces.

(FWIW, everything-is-a-file, the singly-rooted filesystem hierarchy, and
pipes were *the* key abstractions that Unix was designed around. Discard
them and you just don't have Unix anymore.)

+1 for that rant

bronson — Mon, 22 Sep 2008 05:29:40 +0000

Well said!

It's been said that both Fedora and Ubuntu pushed PA too early. I admit, given how bad Hardy has been, this is a compelling point of view. However, if the distros had not pushed early, the great number of audio bugs that have been fixed in the past six months would probably still exist. I bet the distros could wait 3 more years before pushing and it would still be a horrible experience. Software integration sucks, the only way to shake out the bugs is to integrate and see what breaks.

So, between Phonon and PulseAudio, hopefully audio will work decently in FC10 and Intrepid.