I’ve yet find a more infuriating piece of software than PulseAudio.

Here’s how they describe themselves:

PulseAudio is an integral part of all relevant modern Linux distributions …

…gah. Sorry. I can’t believe their lies. Let’s not read that page further.

A random explanation for random readers: PulseAudio is a “sound system” for Linux. To be more specific, it’s a piece of software that sits between applications that play sound, and the sound card drivers that actually deliver the sound to the hardware. The drivers that actually handle the sound hardware are part of the Advanced Linux Sound Architecture, or ALSA.

Basically, PulseAudio allows other applications to connect to them and do interesting things to the sound before it’s actually output to the sound card. For example, you can hook up a program that reads the audio data and analyses volume level - hey presto, you suddenly have a volume meter application, all you need to do is to show that stuff to the user. Easy! Or you can build a visualisation program that reads the stuff going to the soundcard and analyses it. Boom! It works no matter what program is used to actually play the sound. Very nice.

Of course, the only real reason people use PulseAudio is that it essentially lets two pieces of audio-playing software to play sound at the same time. PulseAudio will just take the audio streams from these two applications, mix them, and play them to the sound card.

Which, I might say, is what sound card hardware has been capable of for several decades now. And yes, ALSA drivers are able to handle just this. I can easily have, say, a music player paused on the background while I fire up an YouTube video. There’s technically two applications using soundcard and one is playing back audio. No need to shut down music player. It just works like you expect it to work, even when both apps access soundcard directly. And if I started playing a YouTube video while the music player would be playing, the sounds would get mixed on hardware and played simultaneously.

PulseAudio also capable of making sure that all applications have individual mixer settings. Which is a fancy way of saying that if you’ve spent quite a lot of time setting up your sound levels so that your ears won’t get murdered, there’s still a chance a random app will blow your ears out.

So personally, PulseAudio is just a piece of software that hogs 50% of processor, makes sound playback invariably very very choppy even when it’s just playing one stream from one application, and makes you distrust all mixer settings.

It’s an infuriating piece of software. You can easily play back sound straight to the soundcard anyway, and this is an app that pretends to fix everything by screwing even the simplest things up.

Furthermore, it’s now considered an essential operating system service. All of the modern desktop environments depend on it.

However, you can just keep it running on the background and tell your audio applications to just use the soundcard.

At least, that’s how it worked previously.

I made a small mistake. Goddamn it. In order to troubleshoot why I was unable to play sound in Iceweasel, I decided to upgrade PulseAudio and libasound2.

It seems that in version 4.0, PulseAudio has lost the ability to honour my ALSA settings. PulseAudio is made of evil, and it has always been a sneaky bastard. Now, it has gone completely in a fucking stealth mode.

Essentially, I have ALSA settings set up so that it will try to play stuff to the soundcard. I have set this in the personal ALSA config file ~/.asoundrc:

pcm.!default {
   type hw
   card 1
}
ctl.!default {
   type hw
   card 1
}

Card 0 is the motherboard audio chip, Card 1 is my SoundBlaster Live! card.

aplay -L and asoundconf list will confirm that yes, there’s SoundBlaster there and it is indeed an ALSA hardware soundcard number one.

And there’s no PulseAudio. No sir, these applications know nothing of PulseAudio. Only ALSA soundcards in sight.

Except when I ask my mixer app. Then it insists that there indeed is a PulseAudio device running, and it most certainly is the default.

Or when I fire up a sound player. Yep, definitely going to the soundcard through PulseAudio. Choppiness is there.

Essentially, it seems that nowadays PulseAudio no longer expects me to be able to tell that sound should go to the soundcard directly. No, it expects that if I’m running PulseAudio at all, it should immediately take control of all audio playing, regardless of my configuration.

Mind you, I only have PulseAudio running because every fucking desktop environment insists on it. It’s supposed to sit there dormant and let me just use audio apps directly through soundcard. Because my 2001 vintage SoundBlaster Live! soundcard can do hardware mixing just fine, thank you very much.

Oh, and PulseAudio is nowadays buried deep in the desktop environments. If it’s supposed to be running, it will make damn sure it’s actually running.

I was told that I can get rid of this bastard by saying pulseaudio -k:

% ps ax | grep pulseaudio
11285 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
...
% pulseaudio -k
% ps ax | grep pulseaudio
11654 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
...

Yyyyep, this seems to definitely kill PulseAudio. Which proceeds to immediately restart. Fuck this shit, let’s try it harsh way:

% killall -9 pulseaudio
% ps ax | grep pulseaudio
11768 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
...

Right. Still not quite getting the hint, I say.

Fine, you want to fight dirty, eh? Here’s some!

% PULSE_BINARY=/bin/false pulseaudio -k
% ps ax | grep pulseaudio
12131 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
...

Fuck you, you scheming fucking bastard.

Fine. You leave me no choice. COME FORTH, ANCIENT POWERS! ROOTS OF THE WORLD SHALL CONSUME THE EVIL!

# vim /etc/pulse/client.conf 
...
daemon-binary = /bin/false
...
% pulseaudio -k
E: [pulseaudio] main.c: Taustaprosessin lopettaminen epäonnistui: Prosessia ei ole

VICTORYYYYYYYYYYY! Like a coward it is, it actually totally keels over. But the defaults still somehow appear to point to PulseAudio. Maybe if I logged out and logged in again, it’ll keep pointing to the right devices.

% ps ax | grep pulseaudio
12641 ?        Sl     0:00 /usr/bin/pulseaudio --start
...

…you’ve…

GOT

TO

BE

SHITTING ME.

SERIOUSLY. GO AWAY, ALREADY, PULSEAUDIO. YOU LOST.

% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio
% killall -9 pulseaudio

GO BACK TO THE SHADOW.

OFFEND US NO MORE.

Okay.

Now it doesn’t come back. I think I killed it.

I fire up QasMixer and it shows me SoundBlaster as the default audio device.

aplay defaults to ALSA and plays stuff without chopping stuff up and stuff is actually mixed.

ocp’s ALSA player actually defaults to ALSA. Oh joy.

mpd plays to “soundcard” which turns out to be a soundcard.

Checked GStreamer configuration. Points to hw:1. GST configuration tests work out.

I didn’t actually manage to fix Iceweasel. It probably somehow depends on PulseAudio. But it will rest happy and assured that other applications have already been liberated.

One day, one beautiful day, Iceweasel will play stuff. It will.

Let me guess: In the next version, PulseAudio will have some kind of a heuristic built in it. It will run /bin/false, deduce that it’s a program that consistently keeps on failing, and decides that this daemon-binary configuration directive has to be erroneous and will instead run the default value, /usr/bin/pulseaudio.

In the version after that, it will include an additional heuristic that will notice that /usr/bin/pulseaudio is a symlink to /bin/false, which is obviously something that the user did not intend, and will attempt to either locate the correct binary, reinstall the package from distribution, or failing that, download and/or recompile PulseAudio daemon binary automatically.

After all, the user installed PulseAudio, so this is what they want to do, right? Have it running and have it handle the audio. No matter what.

Seriously, though, this is the closest we have of really infuriating malware in Linux. I really wish desktop environments didn’t actually depend on this bullshit.