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."
Firrrrrsssst P Po Po sssst
When an application can make the soundsystem stop working for all other applications, than there is a bug in the soundsystem, not just the application that caused the problem.
------ Take away the right to say fuck and you take away the right to say fuck the government.
The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients. Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless. No matter how close to bug-free it is, it is an unneeded source of bugs in that case.
This is not entirely true.
Now, I don't know what the exact bugs are that are causing problems. But the API should be stable no matter what happens to the outside. There should be no way to destabilize or crash the audio layer from a usermode application. So, if by "expect more correct behavior from the apps" he means "garbage in, garbage out", then that's fine. But if by "expect more correct behavior from the apps" he means "no error checking and if any app screws up then everything melts", then that's not fine.
I don't know which he means, but I've seen instances of both.
Breaking Into the Industry - A development log about starting a game studio.
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
The 4Front interpretation of GPLv2 is irrelevant - the source code is triple-licensed under GPLv2, CDDL and BSD licenses. ALSA is an excellent example of Linux throwing away a solid API and implementation that could have evolved to support the few critical features it lacked (which is exactly what happened in FreeBSD for example) in favour of a half-baked alternative. The original ALSA API is poorly designed by people who clearly have very limited knowledge of OO principles, but wanted to apply them all the same. This piss poor API was never well documented, and the actual audio drivers are not of the same quality as the ones in OSSv4. The ALSA developers answer to the poor API? Slap another, equally poor, equally undocumented API on top of it. What a fucking mess.
I disagree with the original article: ALSA is the way to go, I have drivers for all cards I've thrown at it, all applications imaginable that support ALSA work just fine for me, and no, as a OSS-to-ALSA changeover survivor, I don't want to change everything to another frigging API yet again (much less back to OSS), thank you very much. And while PulseAudio is less than perfect right now, I recognise it has uses.
But that's just that - it has uses. In its current state, I'm not using it for plain-ordinary music playing on my Debian system. I don't think it's ready enough as a common day-to-day audio routing thing. Still too many problems.
An example case: I was really disappointed when I upgraded Ubuntu on an older computer (600Mhz Pentium III with 256M memory and ESS Solo 1 onboard audio, plenty good enough for OpenOffice.org and web browsing, even ran Compiz at very good performance on GeForce 2 MX =) and sound playback started to just plain suck, when it previously worked just fine with straight-up app-to-ALSA playback. The machine just wasn't fast enough to route stuff through an application, plain and simple. And now Ubuntu foisted PulseAudio in. Uninstall PulseAudio = uninstall entire frigging GNOME desktop. I kept trying to tell it "no, I just want ALSA playback" in sound settings. No dice, pulseaudio kept respawning and hogging audio device all to itself. I kept disabling shit from all places imaginable. No dice, pulseaudio kept respawning. Now, I'm going insane (an unrelated story). I'll be armed with GCC and some dummy binaries. Mheheh. Muahaha. MUAHAHAHAHA. ...any better ideas?
Even if he may be 100% right about that: way not to get the point!
I don't care whether problems are caused by the kernel, a driver, an application, the phase of the moon, or whatever. The thing is, if some "trivial" piece of hardware which has been part of mostly every computer since about 1990, still *does not fucking work* correctly today, I don't give a rat's ass whose fault that is. Especially if it appears the same "problems" have been solved satisfactorily at least 10 years ago on every other OS in mainstream use.
In the meantime, Linux has changed both the audio driver model (ALSA, OSS, who knows what else), and in addition to that, the "application interfaces" (arts, esd, PulseAudio, etc.) so frequently, that it is hardly any wonder that application developers are taking the piss and not updating their software to match the bugs/workarounds to whatever the current "flavor of the week" API for audio interfacing is.
Perhaps PulseAudio is just getting most of the "blame" because it is the most recently changed part of the audio subsystem, so if things used to work before, and now they don't, of course you're going to blame PulseAudio. Even if it is not by itself the "real" culprit.
Every expression is true, for a given value of 'true'
I never thought I'd see a Linux advocate use the Vista Defense! It's the drivers, it's the software, it's something, but it's not my code!
At least with Vista the problems with video drivers, and various other hardware devices was sorted out within a couple of months. In Linux the way audio is handled is an absolute mess.
The sound on my =bare metal= install of Fedora 10 didn't work.
After much forum-searching, config tweaking, and pounding-of-keyboard, I eliminated PulseAudio.
The sound worked.
Tell me again about PA's awesomeness.
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.
A lot of devices stream data over a network and play it locally as audio. That does not necessarily make any of them a "network based" audio device in the sense that they can be driven by PA.
Audio is not unique in needing device ACLs adjusted; it should not need a unique solution for doing that. In fact, having an audio server handle ACL adjustments when something else does that is a violation of the Unix philosophy of chaining together simple tools that focus on one thing.
Application-controlled latency is good. Library-enforced latency is bad. Sending audio from one user-space process to another is a case of the latter.
After reading your post made "as a PA developer", I'm even more down on it than before.
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.