LPC: Linux audio: it's a mess [LWN.net]

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 11:07 UTC (Fri) by nix (subscriber, #2304) [Link]

What? Most Linux users don't care about e.g. muting apps that make annoying sounds while music is playing, or pushing up the volume of important alerts so they're audible over whatever else is going on? Just because they can't *do* it doesn't mean they don't *care*.

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 21:49 UTC (Mon) by lysse (guest, #3190) [Link]

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

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 23:21 UTC (Mon) by nix (subscriber, #2304) [Link]

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

LPC: Linux audio: it's a mess

Posted Dec 8, 2009 7:51 UTC (Tue) by jcm (subscriber, #18262) [Link]

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.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 16:48 UTC (Fri) by iabervon (subscriber, #722) [Link]

I think users almost all want independent volume controls for different audio-producing applications; but I think this is something that users, in general, think is just something computers can't do. (In particular, they want to turn down the volume on applications that just "make sounds" and therefore don't bother to include a control and on applications that want to draw the user's attention unwillingly and turn their own volume up)

I also think most users would like to play their alert sounds out the laptop speakers despite having nice speakers plugged in, but assume that's impossible (and I think it is for a lot of hardware; there's only one DAC that gets switched).

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 8:05 UTC (Mon) by ceplm (guest, #41334) [Link]

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

Posted Sep 19, 2008 17:38 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]

> The 'PA chews CPU when doing nothing' bug (actually a feature implemented
> in a CPU-chewy way) was fixed in PulseAudio 0.9.7, released nearly a year
> ago.

When I said "Doing nothing", I do mean that I was playing a DVD at the time. PA was doing "nothing", in the sense of "adding no value", not in the sense of "being idle". I suspect you are right that killing off resampling would have solved the problem - but I didn't know that, and the default settings were wrong. It seems fundamentally daft to have a daemon handling sound at all.

> alsa with dmix obsoletes the concept of a sound server iff you have only
> one machine or never ever want to produce sound on any other machine, and
> have only one set of speakers, and don't care about per-application
> volume restoration or compatibility with things like esd. Some of us
> care about that.

Actually, that's what drove me mad about PA. I already have a nice setup, with most sounds routed to the default onboard soundcard (/dev/dsp), which connects to the monitor speakers. One or two applications are permitted to use /dev/dsp1, which connects via a USB soundcard to a hi-fi. PA makes it extremely hard to choose specific devices at the application level. For example, I play the BBC's listen-again real-audio streams by using this shell-script:

CACHE=500
DEVICE=/dev/dsp1
LOCATION=$(wget -O- $1 | tr -d '"') #An rtsp:// URL
mplayer -cache $CACHE -ao oss:$DEVICE "$LOCATION"

I'm sure there is a configuration GUI for this, but a few months ago, it just wasn't ready. PA may be a fine program, but it shouldn't be used by default till it has had some more testing, and polish.

BTW, if you want to play sound on a remote machine, ssh in, and use /usr/bin/play.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 22:07 UTC (Fri) by nix (subscriber, #2304) [Link]

It seems fundamentally daft to have a daemon handling sound at all.

Then what do you suggest does mixing of stuff from multiple processes? You can't do it in the kernel, it's solid floating point at least (and more likely some flavour of SSE). You have to do it in some separate process.

btw, dmix forks off a daemon.

(Regarding the rest, maybe Lennart or someone can chip in: I use PA mostly for the network-transparency and volume-choice stuff and have only one sound card and set of speakers.)

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 21:05 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

Please note that ALSA dmix doesn't actually fork a daemon off anymore. Since quite a while actually.

ALSA dmix is a pretty nifty piece of engineering. It allows multiple programs to write data to the audio device hardware buffer simultaneously in a very elegant way. However, this design nonetheless limits the possibilities of it quite a bit. For example, doing stuff such as "glitch-free" directly in dmix would be very difficult.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 21:02 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

In PulseAudio you can switch any playback stream on-the-fly to a differnt device. No command line interaction necessary.

Also, each sink/source in PA has a unique name. You can use it as device string from the command line if you wish.

Sure, adopting PA is a bit of a departure for a couple of old-style Unix philosophies (such as "everything is a file" -- which is a pretty stupid philosophy anyway). But complaining about that is not really a technical argument to me. If we want to have a good, modern sound system for Linux than leaving some Unix legacy behind is the right thing to do.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 0:03 UTC (Mon) by nix (subscriber, #2304) [Link]

'Everything is a file' is a really really really really killingly useful
philosophy: or, rather, 'everything you can usefully manipulate can
produce an fd, and everything with a name is a file'. To see the problems
when this is forgotten, consider the horror which is SysVIPC.

I'm not sure how to apply this to PA though. Maybe a FUSE module reifying
the sources and sinks...

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 0:17 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

"Everything is a file" is crack. It's an attempt of an abstraction that just doesn't work. A file has completely different semantics than sound device. Trying to cramp audio stuff into file-like semantics results in APIs such as OSS.

fds as a handle for resources are useful. But cramping everything into read()/write() style interfacing and access control via Unix permissions is just too simple, and incompatible with all the modern things we want to do with our desktop experience now.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 7:05 UTC (Mon) by nix (subscriber, #2304) [Link]

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

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 10:55 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

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

Posted Sep 22, 2008 20:46 UTC (Mon) by nix (subscriber, #2304) [Link]

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

Posted Sep 22, 2008 20:57 UTC (Mon) by nix (subscriber, #2304) [Link]

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

Posted Sep 23, 2008 9:09 UTC (Tue) by fergal (subscriber, #602) [Link]

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.