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

LPC: Linux audio: it's a mess

Posted Oct 5, 2008 14:57 UTC (Sun) by Joes (guest, #54524)
Parent article: LPC: Linux audio: it's a mess

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.

(Log in to post comments)

LPC: Linux audio: it's a mess

Posted Oct 5, 2008 17:29 UTC (Sun) by nix (subscriber, #2304) [Link]

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.