MPD Mix-up

MPD is a favourite bit of software of mine. It stands for Media Player Daemon, and is exactly that - a tiny bit of daemon software that plays your collection of music. That's it. It keeps a database of song names and tags, but does not impose order on your collection. It doesn't even have a GUI - in true UNIXy tradition, you use a separate client program to connect to it. This means that rather than deal with each music-playing app's own databases and quirks about how it manages your music, you set up MPD once and can then go shopping for the interface you want. Now that I've switched to KDE I use Cantata, but I could still use Ario from my other laptop or CuteMPD on my phone - they can all connect to and control the same music server. It's lovely.

It's been a while since we had a screenshot of anything. Let's have a screenshot of Cantata. Look how pretty it is!

So anyway... most recently I was setting it up on a machine I've recommissioned to hold all my files. And I ran into a bit of trouble. From my old nemesis, PulseAudio.

KHAAAAAAAN!

Now before the PulseAudio supporters barrage my comments section with cries of "You must have misconfigured it!" and "Pulse has always worked perfectly for me!" - (no, please do comment, I could use the traffic) - I just want to say good for you, old chap. Have a pat on the back. I'm sure PulseAudio has worked flawlessly for dozens of people. My experience has been different. It has been a neverending parade of fail for me. This is not an isolated incident. It's nice to be able to use USB headsets and per-application volume levels, but that basic level of stability and usability really needs to be addressed with the basic design of the thing first.

Okay, rant over. Well, for now. Here's the thing: the machine was installed with Kubuntu 14.04, which of course comes with PulseAudio out of the box. Traditionally, running Pulse with MPD has given me problems because the designers decided that the sound server should only start after a user logs in, while MPD takes the more traditional (dare I say logical) approach of "There's one set of speakers; let's run exactly one daemon at system start-up to run them". Either MPD would grab the sound first and Pulse would be silent in my desktop session, or I'd restart MPD and Pulse would muscle in and say "no".

But in this case, I'm using this machine as a server. I'm not going to log in at the console, so I'm never going to be spawning any PulseAudio sessions. Things should be safe, or so I thought, to just tell MPD to use good ol' reliable ALSA to produce sound. And it did indeed "just work". Kind of.

Meowmix, Meowmix, please deliver

When starting the music via the command-line, the first tip-off that something was wrong was how mpc reported the volume level; there wasn't one:-

james@yin(): /yin/mpd
$ mpc play
Daft Punk - Give Life Back to Music
[playing] #10/18   0:00/4:45 (0%)
volume: n/a   repeat: on    random: on    single: off   consume: off

Firing up Cantata, I noticed I couldn't control the volume level there either. What was going on?

Checking the log revealed that it, for whatever reason, was having trouble opening the ALSA mixer device:-

Aug 09 18:58 : alsa_mixer: Failed to read mixer for 'My ALSA Device': no such mixer control: PCM
Aug 09 18:58 : output: Failed to open mixer for 'My ALSA Device'

This error message led me on a merry goose chase of tweaking MPD options, trying to figure out why I couldn't get it to control the PCM volume level, or the Master level, when alsamixer could do it no problems. I set up dmix because it didn't seem to be there already, I tried a bunch of different asoundrc configs from the interwebs, but the only solution seemed to be to bypass the ALSA volume mixer and instead use MPD's built-in software mixer:-

mixer_type                     "software"

This would mean I could make my music quieter than the system volume but it wasn't quite as nice as controlling the audio hardware directly. But it would have to do, I suppose.

It's at this point that most people would perhaps sigh in resignation, and just say "Well, old ALSA has had its day, it's just never going to compete with modern shininess like PulseAudio". We tried our plain old ALSA setup and got back a bunch of errors relating to opening the ALSA mixer. Open-and-shut case.

But not this old and cynical lazycat, no. Inspired by years of embitterment and suspicion, I happened to check one thing that could be causing me troubles. One thing that has been a thorn in my side for far too long, Avatar:-

james@yin(): /yin/mpd
$ ps -ef | grep pulse
mpd       3590     1  5 19:39 ?        00:00:00 /usr/bin/pulseaudio --start --log-target=syslog
james     3601  1849  0 19:40 pts/0    00:00:00 grep -E --color=auto pulse

WHAT?! How can this be so?! I haven't logged in at the console, and... oh! MPD itself is the owner of this pulseaudio process? But why? it's configured for ALSA! We're getting ALSA errors! Well, apparently, there's a setting in /etc/pulse/client.conf that auto-spawns a pulseaudio daemon. I'm not even sure how the sequence of events that leads to failure is happening, but my best guess is that something MPD does at startup is triggering this "super handy" automatic launch of a PulseAudio daemon. At this point, I theorise that MPD has grabbed the ALSA audio device fine, and is about to reach for the mixer device when... Oh! Pulse has already grabbed it. So no volume control for me. Sure enough, editing /etc/pulse/client.conf and adding a line:-

autospawn = no

FIXES EVERYTHING!

$ /etc/init.d/mpc restart
$ mpc play
Daft Punk - Giorgio by Moroder
[playing] #3/13   0:00/9:53 (0%)
volume: 74%   repeat: on    random: on    single: off   consume: off

I guess the moral of the story here is never jump to conclusions about the cause of problems based on what the error logs are telling you. And always be suspicious of PulseAudio. It's out to get you.