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."

Comments

who's to blame.

[delirium of disorder]

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.

Re:who's to blame.

[Anonymous Coward]

Big deal. Scratch your itch! Check out the code from CVS and contribute a fix. Don't just sit there and complain, do something about it! This is F/OSS for God's sake.

I think you're joking up until this point...

How many people would contribute fixes to Microsoft's buggy audio drivers if they had half a chance?

... and now I think you are serious. Not everyone that uses Linux is a software developer. Not to mention, of course, that not all software developers who use Linux would have the time/skillset to approach such a focused project.

Re:who's to blame.

[xtracto]

Big deal. Scratch your itch! Check out the code from CVS and contribute a fix. Don't just sit there and complain, do something about it! This is F/OSS for God's sake. How many people would contribute fixes to Microsoft's buggy audio drivers if they had half a chance?

Bah!
As a computer user I do not have time to do that. The previous to last version of Linux I tried had this "ALSA" sound driver, which was *almost* behaving OK. Then the last version had this "PulseAudio" sound driver which was completely broken. My 10 years old Windows XP operating systems gives me no problems when playing audio.

I put the blame in Distribution makers, who added PulseAudio to "production-ready" distributions when the software is clearly in Alpha stages.

ALSA is on the other hand in BETA stage IMHO. Still, it was good enough.

Useless

[Carewolf]

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.

Re:Useless

[Anonymous Coward]

...Fourth, PulseAudio has a ton of other nice features...

Now if only it would actually play music without skipping, freezing, or using 30+ percent of the CPU. Sheesh!

Re:Useless

[segedunum]

It will, if both your kernel and Pulseaudio are properly configured for low-latency desktop usage (realtime privileges, 1000hz timer, etc).

This is bullshit. No one should ever need to configure a sound system to get it to work on a basic set up and I'm sure that blaming distros or blaming kernels looks like the easy way out. No one needed to configure OSS, no one needed to configure ALSA and no one has needed to configure arts to get sound out of their speakers reliably on first start up. I've seen the mail where Lennart is blaming various Linux kernels for several hundred millisecond latencies and that is simply insane. Either he's lying or you've got a piece of software that is ridiculously sensitive and ultimately broken.

This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.

Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. We've had an unhappy history with sound servers in the Linux world and no one seems to have learned the lesson.

Durability in the face of errors

[ZorbaTHut]

If we make PA expect more correct behaviour from the apps, or that applications stop making particular assumptions about the audio stack, we need to fix the applications at the same time.

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.

Re:Durability in the face of errors

[Sycraft-fu]

A correction here is that DirectSound has not been removed, it is still a major API. What has been removed is hardware acceleration of DirectSound. In Vista/7 all DirectSound audio is software processed. The soundcard can't accelerate any of it.

The real problem was actually that there were few hardware sound accelerators on the market. Most cards were (and are today) little more than buffers you could write data in to to be played. Ok, fair enough. However what happened was that the people who made these cards wanted to support all the nifty hardware features since games made use of them. So they'd write these big complex drivers that played make believe and pretended to do hardware acceleration, all in the kernel of course. That is where the problems happened.

So in NT 6 (Vista and 7) that was removed. All audio is handled in software, and the interface to hardware is just one of giving out the finished sound to be played. Much less room for problems, though more computationally intensive. Not a problem though since processors are much faster.

Hardware acceleration now can only be done using other APIs. That is how Creative Labs does it. They implement OpenAL (their own API) on their cards in parallel to the Windows APIs. It talks straight to the card, bypassing Windows's processing.

That's not the only big usermode DirectX related change though, the graphics subsystem was moved in to user mode too. Though this still does hardware acceleration, of course, the drivers were all moved up to user space. One side effect of this that you notice is that when you install new drivers, you don't need to reboot.

Re:Why is OSS no longer in the kernel?

[LizardKing]

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.

Way not to get the point: why users are angry

[Idaho]

While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications.

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.

The Vista Defense!

[Beelzebud]

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.

A legend in its own mind

[Devlin-du-GEnie]

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.

Re:Article is doomed to failure, but PulseAudio is

[Entrope]

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.

Re:This is the Sound of

[adolf]

All these informed-sounding folks, living in some perfect netherworld that doesn't really exist. *sigh*

If I have a recording that is too quiet (for whatever reason), it is reasonable to be able to turn it up so that it's not too quiet anymore.

Not every recording is stuffed all the way up to the max at 0dB. Some are far quieter, whether on purpose or on accident. If I have a recording which peaks at -20dB, then I ought to be able to apply at LEAST 20dB of gain to it without jumping through hoops.

This is not an uncommon problem, and the best (simplest) solution is just to turn it up -- however that's done. It's been awhile since I've done any serious audio in Linux, but if PulseAudio or ALSA or whatever combination thereof requires me to buy extra hardware (WTF?) to achieve this very simple and obvious function, then it is very broken[1] indeed.

And before anyone replies and says "Oh noes! If we give the users gain, they might makes teh Distortions!!!!" This is broken in the "I'm sorry, Dave, I can't do that" sense. It's REALLY fucking stupid that the same operating system which allows you to do "dd if=/dev/urandom of=/dev/sda" without prompting WILL NOT PROVIDE MEANINGFUL AUDIO GAIN.