Slashdot Mirror
PulseAudio Creator Responds To Critics
Dan Jones writes "As recently discussed here, Linux sound development has come under fire for being overly complex and, more specifically, PulseAudio has been criticized for not being a 'good idea.' In a lengthy interview, PulseAudio creator Lennart Poettering has responded to the many critics of the new-generation sound server and says such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people. While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications."
PulseAudio is NOT unneeded.
First, Bluetooth audio _sucks_ without PulseAudio.
Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.
Third, ALSA's volume controls are horrible and PulseAudio really helps here.
Fourth, PulseAudio has a ton of other nice features: streams tagging and automatic volume control, joined devices, mic boost, etc.
OSS was deprecated because 4front pulled the rug out from under users and started demanding money for binary-only versions, and it was easier to write an entire API from scratch instead of trying to fix the crap they'd left in the kernel.
OSS4 is never going in because 4front has a dangerously wrong idea of how the GPL2 works and think they they have the right to infect applications using this API with their licence.
Do not want!
I've read in several places that the main problem with PulseAudio is not its design and implementation, but its instantiation. Many distributions apparently do not properly set up PulseAudio, causing it to behave unexpectedly. I found this to be the case with Ubuntu 9.04. PulseAudio worked like crap until I followed the following directions to get it set up. It's been working like a dream ever since:
http://ubuntuforums.org/showthread.php?t=789578
LS
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
One problem that many forget looking back on the "good old days" of sound is that you couldn't get sound from more than one thing. On single task OSes like DOS this wasn't a problem, you only ran one app. However for multi-tasking OSes it meant that whatever opened the soundcard first had control until it gave it up. This was problematic for many reasons. Meant that you couldn't even do something simple like play an alert sound from the OS if someone was playing MP3s (not such a problem in the 486 days since those were hard pressed to decode MP3s in realtime).
Well, that's where sound daemons come in. The OS mixes sounds from multiple apps and sends it to the soundcard. Thus you can have multiple programs using sound, just like video. What's more, it'll let you do things like control the volume if an app neglects a volume control. Firefox doesn't seem to have a volume control, but the Windows 7 mixer has no problem adjusting its volume, independent of the system.
There is no reason why this should be a problem. Windows and OS-X do it just fine. There is a sound layer the OS has that you write drivers for an all apps can interface with. You can extend/bypass that with your own APIs if needed (like OpenAL or ASIO). It works really well. For that matter on Windows now they have created the concept of Universal Audio Architecture which is a standard way for devices to expose their functions to Windows, and thus work without device specific drivers.
There is no reason Linux can't do this as well. You can have an audio daemon, and should. What need to happen is time send to be spent designing things in an intelligent way first, and then implement them so that they don't change all the time. Have a standard ABI that the driver writers develop for, and a standard API(s) that the software developers write for. Have standard mechanisms for people to add to or override that if needed.
It'll work fine, if designed well, implemented well, and not fucked with. You can't change the spec every other week. It needs to be laid out and stuck with.
This isn't theoretical, as I said OS-X and Windows do it, and have been doing it for some time.
You should be using OSS4. I put up with the Pulse idiosyncracies until my virtual machines spazzed out. Started researching my options, and found that Open Sound was moving past the deprecated OSS3, which wasn't much better than Pulse.
Since I've compiled and installed Open Sound, I have no more sound problems, period. Everything works the way it's supposed to.
If Pulse and Alsa get their shit together, fine. If not, I'm a devoted OSS fan. Before anyone runs off to experiment, be warned - you will probably have to spend a few minutes purging Alsa from your system. There is no co-existence of the two, at least not on Ubuntu. If you're not a Linux guru, plan on following a how-to, and plan on spending a couple hours getting it right.
http://www.opensound.com/
https://help.ubuntu.com/community/OpenSound
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I'll stick my neck out here. First, Pulse relies on the Alsa driver. There is no hardware issue, and the driver issue seems to be the Alsa driver. OSS4 works on my hardware, where Pulse and Alsa failed. And, of course, the Windows sound drivers work on that same hardware.
People with sound issues on Alsa and Pulse should try OSS4.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png
Man, not that bullshit again...
Let's break this down.
First you have platform independence layers - things like ClanLib, SDL, libao, PortAudio, Allegro, and Open AL. These would be present on any platform. That's the point of them. The diagram seems to go out of its way to mix these in with lower-level technologies, as if to make it less obvious that they're just included to pad out the diagram.
Then there's the trio of obsolete network audio servers: NAS, ESD, and aRts... I suppose if I were to fire up a quick game of xpilot then I might want NAS, but otherwise one can usually assume these days that these three servers aren't installed and don't need to be.
There's FFADO - which is relevant if you're using a firewire audio device... How many people do this? I guess it could be popular among musicians and sound techs - have audio hardware outside the computer's case, accessed via a bus that isn't USB... But this is a driver layer, not an API layer - and these days it seems FFADO provides an ALSA interface, so I think the complaint here is obsolete.
That leaves three modern sound servers (Jack, Pulse, and GStreamer) and two low-level APIs (Alsa and OSS). This is still a bit of an unfortunate mess IMO but nowhere near the rat's nest implied by the diagram.
Bow-ties are cool.