Lennart Poettering, creator of open source sound server PulseAudio, was recently interviewed at this year’s Linux Plumbers Conference. In this Q&A he details the latest PulseAudio developments and addresses some of PA’s critics. Thanks to PulseAudio, the Linux audio experience is becoming more context-aware. For example, if a video is running in one application the system should now automatically reduce the volume of everything else and increase it when the video is finished.
There is not really anyone who doesn’t do PulseAudio anymore.
Well… I do!
I never got it to work right and flawless on my Ubuntu box, probally because some applications simply do not play well with it.
So, first thing I do after a fresh install: Disable Pulse Audio.
You’re not alone. There are a lot of us who uninstall and disable PulseAudio as soon as the OS install finishes.
Rather than add yet-another-layer to the Linux audio stack, why not fix the underlying architecture?
Something I’ve never understood about Linux development in general is the desire to “add one more layer” to fix things underneath. It’s like build a concrete-forms second floor ontop of a the building’s clapboard first floor.
You’ll find that that the argument is that it is best to keep the driver as simple as possible and leave the higher level stuff to get processed in user space – if something is going to go wrong, it’ll happen in user space give that it is where the complexity is located to.
There is also the benefit of abstracting the complexity away so that one doesn’t have to create a new backend for each operating system the desktop is ported to – although having seen the complexity involved with maintaining multiple backends in the abstraction layer, it appears nothing more than moving complexity from one project to another with little gained out of the process.
It’s not just about complexity – they just don’t want floating point math done in kernel, and this is what “future audio” (whatever that means) requires:
Lennart quoth:
http://0pointer.de/blog/projects/jeffrey-stedfast.html
If people wanted a follow up to explain it further:
http://www.osnews.com/thread?331793
Which is why professional linux audio is doomed. OSS4 just works, i can mix low latency and regular latency streams and it works perfect. ALSA+dmix can’t do it and Pulseaudio becomes a hungry beast and eats most of my CPU when i try to do that. Every OS but linux does it the OSS4 way (primary and secondary buffers and in-kernel resampling), The future of audio floating point? please what a waste.. for processing inside an app maybe, but for sending an mp3 to the soundcard? YOU DONT NEED FLOATING POINT. Also you don’t need floating point for resampling in real world usage.
Umm, you realise that you need applications to make professional linux audio a reality; you know things from Propellerheads like Reason, ReBirth, ReCycle are missing.
Considering that they make up a niche of the market – don’t expect it happening anytime soon.
So you ignore all the information given as the causes of problems and you also give no information on your setup. You sound like a person grasping onto straws as your one last lynch to linux hatred evaporates before your eyes.
Edited 2009-10-08 22:03 UTC
Long-story-short: kernels are for drivers. Something providing a service in software, that is not present in the underlying hardware, should probably be outside of the kernel, in a user-space daemon — i.e. Pulse. It really is a very good idea to just have the kernel and device driver do nothing more than abstract the hardware and manage access to it, and leave providing higher-level functionality to userspace daemons.
Just to point it out, Windows does it the same way, so far as I understand it. Windows performs multi-channel mixing outside of the kernel, in a system service, which is pretty much the Windows analogue to a daemon like Pulse. And the Windows service is actually slightly less featurefull than Pulse — albeit also better-integrated and more stable. For instance, the Windows sound service won’t let me move a running application from one sound device to another, and that’s a problem that comes up a lot for me, with my Logitec USB headset, which creates a separate sound output device.
In Windows XP a lot more was done in the kernel, however, with Windows Vista and Windows 7 the audio drivers are a lot simpler with the processing being done in user space. The result has been must disruption but those vendors that updated their drivers had less to worry about as Microsoft took on the responsibilities that the driver vendor used to do.
Pulse Audio’s problem was the number of lazy bum’s who didn’t update their software; Adobe being the best example of a company who kept using OSS for yonks even though ALSA had been merged and stable in Linux; the same problem occurring with Flash and Adobe still using SunAudio even though it has been replaced with Boomer.
Edited 2009-10-08 21:10 UTC
Multichannel mixing in userspace is fine, however you will notice that in windows it’s perfectly possible to use low latency audio (ASIO) while your system still has regular latency audio. This is because the kernel DOES MIXING. That scenario is not possible nowadays with pulseaudio.
He wasn’t talking about random trolls on comment threads. He was talking about major platform vendors.
Wow. I knew the state of sound on Linux system was totally screwed forever, but maybe I didn’t quite know how screwed.
You don’t have to be a troll on a forum to find a list of problems with PulseAudio, nor do you have to be one to read the bug reports.
The mere existence of bug-reports, problems and haters is not necessarily a sign of failure. Even the most successful open-source projects have outstanding bugs, weak spots and detractors (as do closed-source projects, they’re just not as transparent). If you’d like to make a case that PulseAudio has a disproportionately large set of bugs, or that those bugs are more severe, then please, do so.
I’ve mentioned this before, but it’s worth mentioning again: most of the problems that people have with pulse are configuration issues with the way distros ship.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February…
I think pulse audio is a great thing… I just think most distros shipped it before they actually knew how to set it up properly.
PulseAudio should be able to be shipped with a default set of configuration settings and pretty much work by now. If it can’t then there’s something wrong.
The fact that Lennart feels the need to go into that much detail in that mail and that PulseAudio seems to be that finely balanced points to serious problems. I have never seen or heard of even something like JACK requiring that fine balancing act and the kind of latencies he’s blaming on kernel configuration there sound way out of kilter and are completely unverifiable.
Maybe because most people who use JACK use a custom compiled realtime-kernel and carefully selected, well supported audio hardware? Also, JACK is used with apps that have been carefully written to support it.
JACK has a very different feature set from PulseAudio. The overlap is pretty small. It’s possible that they will “grow together” at one time in the future but that’s not even on the roadmap today.
With PulseAudio, people use it with all kinds of cheap hardware with crappy ALSA drivers, badly coded, closed source software with all kinds of ugly hacks. When ANYTHING in the chain doesn’t work properly, be it a stupid kernel configuration like Ubuntu’s default one, missing features of the ALSA drivers, badly coded applications that does all kinds of tricks to bypass the proper, well emulated ALSA APIs, they blame it on PulseAudio. *sigh*
No. That’s rubbish. JACK uses real-time scheduling privileges, but doesn’t need a specific real-time kernel to work well at all. All distributions have packaged JACK. I’ve never seen it need the kind of handholding that is being quoted there. The figures of several hundred milliseconds of latency for various kernels, I cannot see where on Earth he has got those from.
No it doesn’t. That’s rubbish as well. It uses ALSA for it’s I/O drivers.
Yer. It has a proper set of interfaces that Pulse still doesn’t have. Emulating ALSA, again, should have been out of the question.
People use that as an excuse, but you can make a direct comparison between the kind of latency PulseAudio adds versus JACK to achieve the same things – in particular, software mixing. No matter what you do, a sound server will always add latency but what you see coming out of Pulse is ridiculous. If you’re playing a game, turn the damn thing off.
In addition, the Mac or even Windows has combined a regular audio system with something that is good enough for low latency work so I don’t know why people keep saying “Oh, that’s different”.
Excuses, excuses. People have been using those drivers for years now, and if you’ve got something that has broken backwards compatibility then I’m afraid it’s the fault of PulseAudio. That’s the way it is.
ALSA has got to at least a reasonable state where things have stabilised over the past few years and rather than fix the remaining problems, look at the bottom of the stack and ask some serious questions we retrofit a pile of crap over the top of slightly less of a pile of crap to ‘look like’ that slightly less of a pile of crap?
There’s nothing wrong with Ubuntu’s kernel. Using plain ALSA or OSS doesn’t give the levels of latencies that Pulse does and JACK has been packaged with it for some time that works OK. You shouldn’t need the kind of fine balancing Lennart is talking about in that mail to lower latencies, and quite frankly, he’s talking crap.
That’s because if you get something like ALSA to a reasonably stabilised state, as well as OSS being able to have and ALSA interface and vice versa, and you then get another self-important piece of software coming in over the top that sets everyone back then it is its fault.
Seriously, this kind of brain washing and mental illness over PulseAudio will set using Linux back on the desktop years. We’re back to around 2000/2001.
Oh, sir, you managed to capture the core problem of Linux.
When JACK is running, non-JACK applications can’t play sound at all unless you use the jack alsa-plugin and that has the same (or worse) kind of backwards compatibility problems that has given PulseAudio its bad reputation. Even dmix has these problems, with the difference that it transparently falls back to direct hardware access so you don’t realize it until you try to make another application play sound.
You can get pretty low latency with PA with proper configuration and a properly configured kernel. It will however use much more CPU time and drain your laptop’s battery faster. That’s the price to pay for superlow latency. It happens with JACK also. PA tries hard not to drain your battery.
Ubuntu shouldn’t ship with PA as its sound system without adjusting the system, applications and PA itself to work properly with it.
No, PA is not perfect. There are plenty of optimizations left to do, lots of features left to implement (particularly in the auto-configuration department) and many bugs to fix. Nobody is denying that.
I somewhat get the feeling that the same persons who are loud opponents against PulseAudio also were (or still are) against things like XGL/Compiz (“Playing videos worked much better with plain xvideo!”, “Compositing sucks! It makes my Doom III drop frames!”, “Window shadows don’t make my Firefox render any faster! Useless!”). Now, a few years later, about all of the early issues have been fixed and the Linux desktop has become a LOT more modern (and nicer to use) because of it. I defended Compiz back then and I defend PulseAudio now, but I DO recognize that it has caused problems in certain areas and that it’s partly unfinished.
OK, that’s just assanine. I, for one, have no significant problems with Pulse. It’s been more stable than the sound server in Vista (where unplugging my USB headset got me a blue-screen), and I’m not getting any noticeable latencies (and I am playing games on my Ubuntu box, actually). The worst I’ve gotten from Pulse, in the, what, 18 months I’ve had Ubuntu 8.4 installed on my Acer lap-top, is wonky channel names — which is not exactly the end of the world.
And we’re damned well not in 2000/2001. My first Linux (IIRC) was Slackware 8 in 2003, and I don’t recall ever getting any kind of multi-channel sound mixing to work (with just Alsa), after spending about a week trying. Pulse has worked without any configuration effort on my part on all the installations I’ve tried it on, and I’ve never seen noticeable latencies from it (certainly not what I’m getting from ESD on RHEL4 at work!). You can complain about legitimate problems with Pulse all day long, but that Linux audio has come a long way from six years ago, and to claim otherwise is laughable.
What’s sad is that every other Unix-like OS back in 2000-2003 had working, multi-channel sound, using OSS. It was only Linux that didn’t.
Just think how much further we would be without the long detour that is ALSA, which has been extended by Pulse.
It’s fun to see people blaming Pulseaudio for breaking things, but they won’t mention the problems that the linux audio stack had and Pulseaudio has fixed. It also seems it’s getting trendy to say that Pulseaudio sucks because the linux audio stack is not perfect.
And to try to look smart, people will suggest ideas like going back to OSS and kernel-mode mixing, just like the BSDs and Opensolaris, because it’s the Unix Way ™. Yeah, Windows and OS X have a much better audio experience than Linux, and Windows has switched from kernel-mode audio mixing to userspace audio mixing in Vista, but what they know? We should follow the lead of BSDs and Solaris and use OSS. Because, as everybody knows, those two are the desktop OSes most used in the world, specially by audio hardcore users. So indeed, Linux should try to follow their lead, since their audio experience is much better than what Linux, OS X and Windows have.
The thing is, myself I’m happy with Pulseaudio. And from what I’ve seen, most of people is also happy with Pulseaudio, because It Just Works. They don’t even know it exists. For a long time it was experimental and young, but it’s getting more and more mature, and it will mature even more, it will have even less problems, it will solve even more issues, and people will love it even more. The Pulseaudio haters can’t change that, and that hurts them, but they won’t stop saying everywhere that Pulseaudio sucks based in their experiences from years ago.
Edited 2009-10-08 21:04 UTC
Double-plus agreed.
As i said in other posts, the problem is not userspace or kernel mixing of multiple applications. The problem is mixing low latency audio with regular latency apps audio, something that Windows and OSX are able to do with CoreAudio and ASIO, that even Linux with PulseAudio can’t. For that you need to be able to mix both a low latency and regular latency streams in kernel, possibly doing some resampling, otherwise a lot of CPU is wasted. Windows and OSX still do this in kernel.
No, what you need is a realtime kernel. Good news: The full set of -rt patches are about to be merged into Linus’ mainline kernel.
With PulseAudio you can change output device on the fly while the application is playing sound. Start JACK and PulseAudio can be automatically reconfigured to use JACK as it’s output device. When JACK is stopped it can go back to output to the soundcard directly again.
This way you can have the best of both worlds. Super low latency in your pro audio apps (talking to JACK directly) and all the features of PulseAudio for everything else.
Alas, what has happened is that what PulseAudio has sought to fix has been rather inadequate and what it has broken that has worked with plain ALSA, OSS and even dmix has outweighed anything it ‘may’ solve.
It’s utterly laughable that some people think ‘that’ is the way to fix an already flimsy audio stack that has at least started to work over the years.
That doesn’t mean that it is right for everyone else. Alas, PulseAudio is not the right solution for userspace sound handling regardless. However, there is still a sizeable proportion of processing done in the Windows kernel, and it certainly is in OS X. Don’t be fooled.
PulseAudio is there not because it is a better solution but because it is intended to be a massive bandaid for apparent problems lower down.
Dream on. Let’s just pretend the bug reports and compatibility issues don’t exist. That’s why people won’t use Linux desktops. I can’t believe people still use that stupid ‘Just Works’ bullshit.
Edited 2009-10-08 22:30 UTC
That doesn’t mean that it is right for everyone else.
And that doesn’t mean it is not the right solution for linux either. In fact, linux developers seem to like putting that kind of things in userspace. Personally I trust more audio developers and distro packagers than a bunch of users who happen to hate ALSA and Pulseaudio.
Dream on. Let’s just pretend the bug reports and compatibility issues don’t exist.
Let’s also pretend that all the happy Fedora/Ubuntu/etc users of Pulseaudio that have no problems with audio in their system don’t exist. Let’s suppose that all the distro guys are stupid and are choosing Pulseaudio because they don’t know what they’re doing. Let’s also suppose that users won’t miss all the features that Pulseaudio has and they would lose if it was removed. Let’s also pretend that the bugs reported are unfixable, and let’s just throw random FUD and say that those problems arise from the way Pulseaudio is designed without explaining why
Edited 2009-10-08 22:57 UTC
Which is what I said. 🙂
Unfortunately that won’t make the real problems that do exist go away. Note that Lennart still feels the need to say this:
That’s one of the most arrogant piles of crap I’ve read regarding open source software, and that’s going some.
It’s a totally flawed argument to say “Oh, they’re packaging it so you must be wrong”. Linux distributors have proved that they’ll package anything up and throw it in without a thought for what’s going in there.
The only two features even Lennart has come up with is per application volume control and ‘glitch-free’ audio, which I find hilarious. Quite frankly, that hasn’t been worth creating yet another audio layer for and it hasn’t been worth breaking existing applications.
For starters, PulseAudio has to work with existing applications and it implements a completely inadequate and inferior ALSA emulation layer that still doesn’t work with all applications, so yer, it breaks things. Great. Advice is still to write for the PulseAudio safe subset of ALSA. I haven’t seen anything that changes that and I still don’t know if libsydney is anything other than vapourware. If you don’t know why this is likely to encounter some serious problems –
http://upload.wikimedia.org/wikipedia/commons/1/14/Pulseaudio-diagr…
– you’re not much of a software developer.
So yer, let’s talk about it. 😉
Running PulseAudio on Ubuntu, it’s working just fine here, but I cannot help but wonder what the point of it is.
So support for 2 or more sound cards is nice(TM), but I can’t imagine anything other than the vast majority of users never having any use for that.
And as for per-process volume control? Yeah, nice… running pavucontrol right now causes the pulseaudio process to consume 25%+ CPU on this laptop. Now this wouldn’t be so bad (actually… wait… yes it is!) but pulseaudio has a built in counter that checks how much CPU it uses and if it goes over a certain limit, it shuts down. And what does that mean? Well of course your sound goes *poof*.
Again, WHAT! IS! THE! POINT?! If you can’t use the feature without it disabling all sound then what good is it?! And here is the best part — it’s not a bug: https://bugzilla.redhat.com/show_bug.cgi?id=456623 – in other words don’t ever expect this crap to be fixed if redhat has any say in it. At least Ubuntu hasn’t closed their bug report — yet. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/373450
Hmmmmmm…..right………
So if you expect low latency from PulseAudio it will eat a sizeable chunk of your CPU time? Someone tell the Jack guys that they missed a trick there. Goodness me. This is sheer amateur hour.
Edited 2009-10-08 22:23 UTC
You’re not thinking four-dimensionally! I have three sound input devices – my sound card, my USB headset and my webcam. It’s not “support for 2 or more sound cards”, it’s “support for all the audio input devices people have plugged in these days”.
If Pulseaudio is using 25% of your CPU time, then it’s a bug. It doesn’t do that here. The per-process volume control is fantastic when you’re playing DVDs/BDs and keeping an instant messenger open in the background.
I also have to add +1 to the person who said “All the people complaining about Pulseaudio are neglecting to mention the problems that were present before with ALSA and OSS”. Since Ubuntu 8.10’s Pulseaudio and installing padevchooser, I haven’t had any problems with sound. That’s got to be saying something.
Take a look at the bug report – Lennart has specifically said that yes, it does actually happen, and no it isn’t a bug. This is apparently what PulseAudio does to lower latency.
Wow, they want to lower the volume of other audio when a video is playing? Why the hell are they putting their time into this instead of, I don’t know, fixing the CPU eating bugs in PA? Now, I feel that PA or something like it is necessary given some of the issues I’ve seen with ALSA/Dmix, but keep it simple first. Make sure the core functionality works and doesn’t eat a ridiculous amount of CPU before we add bling features, ok? And as for the volume of my movie versus other sounds, I’ll set that myself thank you very much. That’s what the per-process volume controls are for, right?
…With the fury of a thousand suns. It has NEVER worked right for me on several machines. I still have it on my Acer laptop because I’m too lazy at the moment to get Alsa running right. I have weird issues with PA all the time; Audio controls -both hardware and software- stop working sometimes leaving my audio at whatever volume I last set it at. My Mic will stay on no matter what is muted. I’ll get stuttering under relatively high CPU usage. It absolutely despises speedstep. My CPU bounces around 800 to 1600mhz and whenever it shifts, I get audio glitches.
And this is on a Core Duo 1.6ghz dual-core laptop with 2GB ram and a relatively quick sata HDD. There is NO reason for audio to be this flaky in 2009 on modern hardware. My freaking NEC Versa P/75 with 40mb of ram running windows 95 can play MP3s smoother than my 3 year old laptop.
Bring on the “well you have everything configured wrong” and/or “it works for me! you must be an idiot!” comments.
*sigh*
it works for me so you must be an idiot, helf.
I was flamed of using ™s, but this one really deserves one!
WorksForMeSoSTFU(tm) 🙂
Oh sorry, I forgot that on internet people have forgot how to read and irony does not work without smileys.
I thought it was pretty obvious, repeating helf’s almost exact words but whatever.
Edited 2009-10-09 15:34 UTC
heh. yeah, sarcasm doesn’t come across on the web unless you use tags or something. It is kinda sad.
My lap-top sounds like it’s very similar to yours; I forget the exact model, but I have an Acer, 2 GHz Core Duo, with 2 GB of ram. I don’t have any of the problems you’re describing; Pulse works pretty well for me. What distro are you using, and are you using the Pulse that came with it? I’m kinda curious as to why you’d have severe problems when I have none on similar hardware.
At the moment its Ubuntu 9.04. And yes, its the PA that came with it. Any idea what your sound hardware is? I need to double check and see what mine is.
on practice I’m staying clear of it.
Too many open bugs, too much CPU usage. When they get it minimally right I may reconsider.
It is already enough to me to live with the crap Flash brings to my “computing experience” right now.
that I haven’t had any audio problems in Linux since forever. Whatever defaults Ubuntu is using (PA? dmix? don’t know, don’t care) works just great for me.
Ubuntu (8.04?, 8.10, 9.04) are using PulseAudio.
In 8.10, I could only have sound from one application at a time. 9.04 is mostly working*.
* http://bugs.winehq.org/show_bug.cgi?id=10495
Edited 2009-10-09 17:24 UTC
PulseAudio has caused me nothing but headaches on my ThinkPad laptop. With that said, I’m not going to blame PulseAudio for all the problems, but that doesn’t mean it should not be blamed at all.
One fun issue was that PulseAudio had problems when the laptop was brought back from sleep that could cause another program in GNOME to go on a memory eating rampage.
It also is a CPU hog, and not having audio in Flash is just crap, even if the problem lies with Adobe (of course Flash is the spawn of the devil, but that is for another rant.)
So once I learned how I disabled PulseAudio and I’m fairly happy now, except of course only one program at a time can use my sound card. Pretty shitty, but I’ve adjusted.
In general the Linux sound situation is a horrible mess. I hope we can have a better situation in Haiku.
I think that is the case since PulseAudio is basically just replicating the BeOS Media Kit that worked 1000 times better in 1997. Haiku’s Media Kit still needs work of course, but in general I think the future is brighter there.
You should be able to use multiple audio applications at once with ALSA. Take a look at your distros documentation how to remove pulseaudio without breaking ALSA.
In theory, sure; I’ve yet to see dmix actually work. Albeit most of the times I’ve tried, it’s been with old-Alsa, so maybe that’s changed?
I have not used Linux that long (converting from windoz) but, I have found that they only way to get the sound to play correctly in VirtualBox OSE is to use pulse.
Pretty much. I’m using RHEL4, and I’m using VBox to run RHEL5 and WinXP. I haven’t been able to get Alsa/dmix working, despite several hours spent trying, and I’m to lazy to resolve the dependency-hell to build either Pulse or a newer Alsa than what’s available. So I just don’t have sound from my Guest OS’s.
That’s kinda what I’m saying; pulse-haters aren’t being realistic about how much worse life is without it.
Linux won’t ever have software mixing in kernel. Get over it. Pulse does very well by doing it in userspace, and with realtime support it’s about the same thing (expect if app tries to use non-virtualizable kernel interfaces and/or to access directly hardware buffers which is primarilly why OSS apps have problems and can’t have latency they expect – because there is a software buffer between real one and the app).
Yes, PulseAudio was introduced prematurely, but it got much better recently.