Why I don't like Pulseaudio
(This rant was originally part of the live streaming series, but I moved it to a separate article because people got stuck on it instead of responding to the actual subject of the article.)
Before I get flamed for attacking Pulseaudio (PA), let's just settle this: I don't like it. I think PA is over-engineered and tries to do too many things at once. I used to (until just now) systematically purge pulseaudio-related packages from my system, mainly because PA has this awful tendency of automatically starting and staying around eternally, which wouldn't be so bad except PA has also the bad habit of hogging the audio device exclusively, which makes regular programs like mplayer, ogg123 fail to simply play audio, unless they go through the PA straight-jacket. (Update: this seems to be a bit better in newer versions of PA, where the audio device is released when sound is not being played. Thanks Philipp Kern for the correction.)
In the GNU/Linux audio stack, we already have another system that supports multiple accesses: ALSA itself, so I believe that PA should at least behave nicely to other apps, and it seems I am always having problems with that. (The fact that ALSA itself is over-engineered is also telling of the poor state of the audio stack in GNU/Linux.)
The other beef I have with PA is the Not Invented Here syndrome: instead of extending existing tools like ALSA or Jack, people just figured they could do everything better and start from scratch. So now we just have one more "standard" way of playing audio, good job Lennart.
So this post is not about why I don't like PA or how ALSA is so much better.
(I think ALSA also sucks, but my point is that the solution to that is not to add yet another layer of crap on top of it. You seem quite familiar with those internals, so I am in no position to argue about this, yet it seems to me that the wrong assumptions built into ALSA could be fixed instead of adding layers on top. And if ALSA plugins can fix those assumptions - where's the problem?)
I am using PA now, so please let's not get into this debate of PA vs ALSA - unless some patches are waiting in a queue somewhere.
Well that's too bad, i guess that will teach me speaking my mind about the utter mess that Linux audio has become.
You are right, PA does release the audio device when it's not playing. That is the case in wheezy, at least, but I don't remember this working in Ubuntu Lucid or Debian squeeze. But the fact that it monopolizes it instead of sharing it with other ALSA citizens is still annoying.
Seems to me PA could share the audio device with other ALSA consumers...
Another Debian developer pointed me towards (ironically) a great bit of documentation on the (as usual) excellent Arch Linux wiki:
https://wiki.archlinux.org/index.php/PulseAudio#ALSA
Basically, there's an ALSA plugin that makes non-Pulseaudio software talk to PA through a regular ALSA interface. It seems sick, but it's a good way to workaround on of the major complaints I am having here.
There's also documentation on how to properly make PA talk with ALSA using
dmixso that the device is opened "shared".So I guess I have to like PA a little more now. Anyways, it worked for what I needed to do, so kudos to PA (and Lennart, sorry about that) here.
You should probably change the title of your post to "I don't like pulseaudio because I don't know what it does and how audio works and because it is new"
That should summerize your position nicely.
The MMAP-availability assumption is unfixable in any architecture that insists on the concurrent access to the mixing buffer. Yes, there is the undocumented mmap_emul plugin that can provide a fake MMAP even on top of software encoders (including Bluetooth's SBC). I don't know if this is enough to make dmix work after the removal of the lines that check for the hardware device.
However, the next problem is the fact that ALSA's config (where you would put that connection between plugins like plug, dmix, mmap_emul, ac3 and spdif) is a complete programming language, and a poorly documented one. Applications should, in theory, be prepared to run on top of any config or complain if it doesn't have the needed features. But in fact they are tested only on top of the default "plug+softvol+dmix" chain or the pulse plugin. In fact, ALSA itself was segfaulting some time ago if a plug happened to be placed (redundantly) on top of another plug. Programmability is bad where a one-size-fits-all processing pipeline can exist.
So, pulseaudio is an attempt to leave only hardware access to ALSA and replace (the distinction between "augment" and "replace" is important here) its stupid plugin system with something that was intended to work out of the box for everyone and (unlike the pure-ALSA setup) keep the guts inside. So, in my viewpoint, "release the audio device" is not even a valid argument - if you want your sounds mixed, they need to go through the software mixer, which is pulseaudio. Yet, due to the added features like consolekit integration, it indeed does not work for everyone.
I'd say that everything will become an utter mess if old unfixable stuff (I am talking about plug and dmix in this case) is not removed.
See - you have a system with bad assumptions. You design a better one. Now you have two systems (old bad and new presumably good), and interaction problems between them in addition to the problems that the old one had.
To think that ALSA’s dmix hackery solves the problem of software mixing is really not knowing it correctly.
Of the other software that do software mixing correctly, you have: - OSS4 but it is in-kernel and driver coverage is bad - JACK but it doesn’t have the same target at all - aaand yup, that’s all.
That makes a good reason for pulseaudio to exist, don’t you think?
I have a USB DAC (a dragonfly) for spotify, but when I play video through HDMI, I want the sound to go there.
On a Mac, I can set up an output device per application, and it just works. And it remembers. That's exactly what I want.
But the machine in question is not a Mac. It runs Xubuntu 12.10 with pulseaudio. And guess what? It works exactly the same as on a Mac, with a very easy to understand PulseAudio control panel. Flawless audio as well. And when I changed my desktop to Ubuntu, it still just works. In the past five years, my approach to pulseaudio has moved from removal, to apathy, and now to gratitude.
Hindsight is 20/20, as they say... I learned a lot from the comments here, indeed, and unfortunately not from yours. :P Besides, there wasn't room for such a long title.
As for the "how audio works", I feel I have sufficient knowledge of how digital audio works to make the claims that I did in that post. I did not know PA well enough, it seems, or more accurately: the recent PA versions have improved to a point where most of my criticism were rendered inaccurate, but I don't think it's fair to extend this to my general knowledge of audio. Of which you probably know nothing.
So one other thing I have seen about this: when I plug MPD into PA, it creates its own PA daemon, which other users can't seem to talk to. That is a problem, because all audio for other users will hang as long as MPD is playing.
How does PA handle multi-user scenarios like that?
For the record, I am using Pulseaudio more and more, mostly for RTP streaming. However, I am still seeing serious issues with locking because multiple users need to run Pulseaudio - mpd, liquidsoap, and my own user...
The other problem is I have seen crashes and hangs. One is particularly annoying:
This process has been hanging for a few days now, with no end in sight: kill -9 doesn't kill it, and both strace and gdb hang when trying to attach.
Another problem I had was an assertion raised:
I need to report those bugs, but right now at least one user on my system can't run pulseaudio at all, his PA process being simply hanged.
Update: here's the bug report.