LPC: Linux audio: it's a mess

Posted Sep 21, 2008 21:02 UTC (Sun) by mezcalero (subscriber, #45103)
In reply to: LPC: Linux audio: it's a mess by Richard_J_Neill
Parent article: LPC: Linux audio: it's a mess

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] (6 responses)

'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] (5 responses)

"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] (4 responses)

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] (3 responses)

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] (1 responses)

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 (guest, #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.