![]() | |
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.
This comment has been removed by a blog administrator.
ReplyDeleteI know the feeling, I always have to deactivate flat volumes in Pulse. Also, don't talk to me about Kubuntu, I really dislike where they've taken the distro.
ReplyDeleteEnough bitterness, it's always nice to learn new little hacks for the sound system, and I'll keep this one in mind should I ever need it.
This comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteI mean I guess it's nice that this post was popular? But my next blog rewrite will just not bother with comments.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete