PulseAudio Creator Responds To Critics 815
Posted
by
kdawson
from the louder-please dept.
from the louder-please dept.
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."
Why is OSS no longer in the kernel? (Score:3, Interesting)
I've read the background articles (but not the featured rebuttal about PulseAudio yet), and I was wondering why OSS was "deprecated" in favor of ALSA and whether (and if not why not) there's a possibility of OSSv4 being put back into the kernel. Anyone know?
Among other distros, Ubuntu... (Score:5, Interesting)
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/>
Re:Useless (Score:3, Interesting)
From the wiki http://www.opensound.com/wiki/index.php/Main_Page [opensound.com]:
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.
floating point works fine in my kernel (Score:3, Interesting)
The FPU works perfectly fine in a Linux kernel. The RAID code can even use MMX, SSE, AltiVec, and so on. Observe:
kernel_fpu_begin();
do_stuff();
kernel_fpu_end();
The same goes for pretty much anything else, Bluetooth included if you actually care.
Even better, in the kernel I can get the ultimate in real-time performance. I can get working fine-grained security like SE Linux instead of crap like that offered by the X server.
Win, win, win. Kernel code rules.
Re:Durability in the face of errors (Score:5, Interesting)
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.
Programming in general, is a lost art for Linux (Score:3, Interesting)
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 [catb.org], 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.
Re:who's to blame. (Score:5, Interesting)
I'm also slightly disturbed by his attitude to other operating systems than just Linux. For example, this post [mail-archive.com] 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.
Re:Useless (Score:5, Interesting)
"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.
Re:Ubuntu is ruining Pulseaudio's reputation (Score:3, Interesting)
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.
Re:Too many choices.... (Score:2, Interesting)
I have to reply. I've been using Linux Audio for years making music. I rarely have to do any setup even after a system upgrade. If you use Jack and applications that support it - of which there are many, it's stable as a rock.
Ugh, Yea, Pulse sucks (Score:3, Interesting)
I was using PulseAudio for a while. Every time I booted up I'd have to manually restart pulse. Then one day it just stopped working entirely. So then every time I booted I'd have to manually stop pulse and start alsa. Then that stopped working entirely. Finally I just completely removed PulseAudio, and everything has been working perfectly ever since.
Re:This is the Sound of (Score:2, Interesting)
Turning the volume louder than the total of 0db demolishes your speakers, unless you have mid, high and lows. In other words: if OSSv4 allows you to do that then OSS sucks and the OSS devs know very little about sound other than turning data into soundwaves -_-'
Re:Ubuntu is ruining Pulseaudio's reputation (Score:2, Interesting)
Re:This is the Sound of (Score:5, Interesting)
And even if it doesn't actually damage anything, amplification can cause clipping [wikipedia.org]. 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.)
GStreamer? (Score:3, Interesting)
Whatever happened to GStreamer? I thought that "circuit/pipeline" model for building audio systems would make it easy for developers, and foster a whole new generation of interfacing audio to apps, and people to each other by audio. Where did that catchy future go?
Re:This is the Sound of (Score:3, Interesting)
Interesting. To be honest, I don't know much about speaker design. Why isn't there hardware in the speaker for cutting off the signal before it can cause physical damage?
Re:This is the Sound of (Score:3, Interesting)
While I agree with you generally, sometimes this just isn't an option (i.e. audio source too quiet to hear, only speakers available built into your laptop).
Re:who's to blame. (Score:3, Interesting)
Pulseaudio rocks IMO.
I have 7 Internet-connected personal machines at the house (7 Linux boxes, 1 Wintendo), and one Linux laptop is connected to a 5.1 surround system in the office.
Every machine on the network (with the exception of the Wintendo) can play audio over the network through the 5.1 surround system via Pulseaudio, with no appreciable loss of sound quality.
I can sit on the couch with a wireless-enabled laptop and play music from the headless file storage machine through the 5.1 surround system remotely.
We've come a long way, baby.
ALSA devs are to blame for this mess (Score:1, Interesting)
PulseAudio is a source of many problems, yes, but it's no worse than all the other bandaids, like Esound, NAS, etc.
The reason why all these bandaids were introduced is because ALSA devs continue to refuse to make the kernel audio devices multi-open. In any sane world, opening an audio driver a second time would not fail or hang or stutter, but instead would AUTOMATICALLY connect all audio inputs to a kernel software mixer and hence work transparently.
Instead, because the ALSA devs are utterly insane, they require dmix to be configured up for ALSA apps in user-space, and provide no direct multi-open driver for legacy applications. As a result, audio in the Linux world is just borked. It doesn't have a hope of working in the presence of the billions of legacy audio apps or with proprietary crap like Flash for example (and if Flash works then something else won't, or a second instance of Flash will break, etc). And that's why crap like PulseAudio gets invented as a bandaid.
Sure, PulseAudio is a royal pain, but the people who deserve the worst kicking are the morons at ALSA, who for years have refused to add kernel multi-open to their audio drivers for no sensible reason.
If ALSA continues along its current path of total myopia, the best solution for Linux is probably to scrap ALSA and replace it with the latest OSS. Then no bandaids will be needed.
Re:This is the Sound of (Score:3, Interesting)
your speakers need to be rated at better than the amplifier's peak power
No.
The easiest way to destroy speakers is to have too "small" amplifier (one without enough power), not too big.
Reason: when amplifier is pushed to the limit it will clip (or worse) which will create a lot of high frequencies which will burn the (relatively low rated) high frequency element.
With high enough power your ears will control your brains which will control the remote which will control the amplifier power - down.
This very usually happens before any speaker element is destroyed (but not always). The effect on your ears is left as an non-exercise for the reader.
Re:This is the Sound of (Score:2, Interesting)
There is a third one: glue. Guess what? What happens when your speakers fibrates so hard that the glue cracks? Yup. You have fucked up your speakers. You see whith ear phones a lot. A workouround for this is suck and blow a little in the earbuds, but after a week or 2 or so you will need to buy ned ones. ;)
Re:The problem isn't the idea (Score:1, Interesting)
You can easily find recent PA-related horror stories in Fedora bugzilla (by people running fedora-devel, ie the latest bleeding edge PA on the preferred distro of PA's author).
These reports are usually closed when the reported gets too disgusted to carry on.
Re:This is the Sound of (Score:3, Interesting)
Nice.
Remember when I wrote about jumping through hoops? THAT. I don't want to have to massage every bit of quiet audio that I encounter, FAIL or not. I just want to turn it up so I can hear it.
There is PC audio outside of music MP3s on a disk, anyway. Youtube comes to mind. So does Google Voice. And so does the stuff I yank out of my pocket voice recorder. And then there's Shoutcast. And. And. And.
I suppose I should concoct a way to deal with increasing the levels of each of these things when they happen to be too quiet, just so that I can work around PulseAudio's lack of gain?
Talk about fail.
Re:This is the Sound of (Score:4, Interesting)
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 [adobe.com]
Re:This is the Sound of (Score:3, Interesting)
Difference with FreeBSD? (Score:2, Interesting)
Re:All you really need to know (Score:3, Interesting)
What would be the point of that? FreeBSD is doing a good job of being FreeBSD. You like it, go use it and stop ear-bashing.
Translation: "FreeBSD works, and you want something that works, you say? Then go use FreeBSD. With Linux, we continue to support elitist incompetence. When critical operating system infrastructure doesn't function, we don't fix it; instead we make excuses for the developers who are responsible for the mess. We also try and humiliate and/or discredit users who complain about this state of affairs, and tell them to stop being such big meanies.
We also insist that we know better than the authors of the initial UNIX operating system, even though their software worked, and ours doesn't."