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."
Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless.
In fact it's worse than useless (on Ubuntu): whenever I move away from my wireless access point at home (i.e. I'm on my bike on my way to the university), my sound stutters; this is probably PulseAudio spending too much time on making a new map of the network and too little time on actually handling sound waves (but I'm speculating).
Did no one test this? Am I the only person using a "ThinkPod" as a portable music player? Oh, I guess it's not one of those 95% most common use cases, so it's no biggie if it isn't handled properly.
Except that there are twenty disjoint chunks of 5% least common use cases not being fixed because they don't affect that many people, except everyone is affected by one... grr... </hyperbole> <apology/>
From the wiki http://www.opensound.com/wiki/index.php/Main_Page:
Supported audio formats
- Supports 8/16/24/32 bits/sample audio formats
- Supports sampling rates from 8KHz up to 200KHz
- Supports mono, stereo, quad, 5.1, 7.1 and multichannel audio devices
- Transparent Software based Audio Mixer
- Allows applications to share the same "real" audio device regardless of what format is requested by the application.
- Supports recording and full duplex in addition to playback.
- Ability to mix stereo and multichannel audio streams up to 7.1/200Khz/32bit.
- Supports full 24 bit range without loss of precision during internal computations.
- Each application has its own independant volume controls.
- Supports loop back recording. This enables you to "record-what-you-hear". Typically this is useful for recording streaming audio or trapping audio from applications
- 64bit internal processing guarantees audio fidelity and precision if the audio data needs to be converted.
- New device enumeration and mixer API makes it very easy to manage devices programatically.
It's actually extremely difficult to do a reliable sound system. The drivers for a large number of cards are pretty bad.
From what I understand up until recently most OS' treated sound cards like any other hardware. If you got a bad response from them, the OS would halt the system rather than risk physical damage. Hence sound cards are one of the leading causes of blue screens in windows 9x and XP.
One of the things Vista did right was recognise that drivers for sound cards can't be trusted and put in an additional software layer between the hardware and drivers to minimise sound card related blue screens. It's why Directsound has been removed from DX and one of the biggest reasons DX10 can't run on XP.
I've looked at GNOME, I've looked at ALSA, (indeed, Ubuntu in particular in general terms) I've looked at the bloated instability of Compiz, I've looked at FreeBSD by comparison, (which I use on a daily basis) and at some of OpenBSD's source...and I've come to an important realisation.
When it comes to both design philosophy and code quality, Linux developers suck; and I'm talking black hole level, here. The BSDs leave Linux so far behind that it isn't funny.
What is even worse than the poor code quality, is the level of denial. The GNOME developers in particular have been told on numerous occasions what an abomination their baby is, yet they continue to insist on defending it, rather than actually listening to the feedback they are given, and trying to improve.
The single main problem is what I called the Starbucks generation; self-righteous, latte-sipping yuppie CS graduates, who as said in another post, worship C++ and various hell-spawned forms of RPC, and use such to code bloated monoliths of a magnitude that would give Microsoft nightmares.
They think they know better than the 30 years of UNIX experience that has come before them, including the very authors of the initial operating system itself.
Although I haven't used Pulse, I have used ALSA, and I've used enough other Linux software to know that the Pulse author most likely shouldn't be defending himself; but should be humbly acknowledging that his software is terrible, and appealing to the community for help and insight into how he can do better.
He can start by reading this, and gaining a real appreciation of the system he is writing for.
There are a lot of programmers in the Linux community who badly need some humility. They need to study the designers and authors of early UNIX; they need to learn how those people thought, and they need to emulate said designers' thinking and behaviour.
Above all, more than anything else, there needs to be a return to implementation, rather than interface, simplicity. As priorities, faddishness, popularity, and most of all, the end user, need to die.
I'm also slightly disturbed by his attitude to other operating systems than just Linux. For example, this post on the OpenSolaris mailing list.
Comments such as the following:
Then, "Unix Admin" asked mumbled something about whether we might want to install Solaris on my machines. Thanks, but no thanks. I already got a good operating system, which is called "Fedora", and its audio system is what I am payed to work on by Red Hat.
As mentioned above, we have been adopted by all relevant Linux distributions. There's not much left we could win in Free Software land, except maybe that little OS that starts with "Slow" and ends with "aris". ;-)
appear somewhat unprofessional for someone who is being paid for the development he is doing, and for someone on whom the future of Unix/Linux audio has been entrusted.
"OSS is outdated and has its limitations. "
OSS3 was proprietary, it had limitations, and it sucked.
In today's world, OSS4 is open source, it is actively being developed, and it WORKS! See my post above. I can have three virtual machines open, all of them playing sound, and go back to the host machine, and play music there. No sizzle, no popping, no waiting for buffers.
OSS4. I don't understand why more people haven't discovered it yet. If the idea of compiling scares you, don't mess with it - but I really thought the majority of Linux systems could figure it out.
"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
Lennart gripes in that post about some kernel patches that Ubuntu included -- but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes. (Running in a real-time class can improve latencies because that app gets to run ahead of most other apps and kernel tasks. A lot of the real-time development on Linux has been driven by audio people looking for more controlled latencies, but that was also before PA.)
In the days of yore, Linux applications didn't need to run at real-time priority to get reasonably good, low-latency audio performance. In days of yore, in fact, they got reasonably good, low-latency audio performance on relatively slow hardware before Linux had anything like true real-time priorities. Please explain to me how PA's apparent requirement to run in a real-time priority class on much faster systems is Ubuntu's fault.
And even if it doesn't actually damage anything, amplification can cause clipping. On the other hand, many sources really are too quiet and don't fully exploit the available dynamic range, so having a way to increase sound volume up to the point where you'd start overdriving the hardware would be nice. But that appears to be beyond the state of the art for online algorithms. (Offline, people have been normalizing volume for years.)
Right before all the distributions started switching to PulseAudio, I remember thinking about how alsa was becoming stable (and "the" audio standard), and I wasn't seeing anyone with sound issues anymore.
Granted, alsa alone isn't as versatile as pulseaudio, but there is value in sticking to a 'pretty good' solution, even if it might not be the best.
An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png
I fear the Y2038 bug