Saturday, June 29, 2013

Followup on mute/aumix not working on ubuntu 10.10+: error opening mixer

You know, sometimes I feel like crying.

Whenever something just works, somebody comes along and sticks his/her fingers into it until it stops working. Remember when I told you about the convenient little mute command on my Debian Lenny? Well, when I tried it on Ubuntu 11.10, imagine my surprise when it said "error opening mixer: no such file or directory".

A quick glance at the source of /usr/bin/mute revealed it to be a convenience wrapper around amixer - which I also told you about already.

Here's the source of /usr/bin/mute like I found it

volumes=$(aumix -vq |tr -d ,) 
if [ $(echo $volumes | awk '{print $2}') -ne 0 -o \ 
        $(echo $volumes | awk '{print $3}') -ne 0 ]; then 
        aumix -S 
        aumix -v 0 
        aumix -L > /dev/null 
Well, well well, what have we here. They're actually using aumix a lot like I did in my volume bar script, to generate easily-parseable output.

A  quick strace revealed this:

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 
fstat64(3, {st_mode=S_IFREG|0644, st_size=4443504, ...}) = 0 
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7580000
access("/dev/mixer", F_OK) = -1 ENOENT (No such file or directory) 
open("/dev/sound/mixer", O_RDWR) = -1 ENOENT (No such file or directory) 
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb779f000
write(1, "\n", 1) = 1

So the mixer device is missing. This should in principle be easily fixed by installing the oss-compat package - which unfortunately in my case was installed.

A bit of research helped me understand some of what is going on. oss-compat doesn't do much else but modprobe some oss modules into the kernel, e.g. snd-pcm-oss. Unfortunately, a system- and repository-wide search for said modules came up blank. Without anything to modprobe, the oss-compat package is as useful as a fire hose without water. This link here tells me that the bug was "fixed" by blacklisting whatever stuff - in my book that's sticking your head in the sand if I've ever seen it. Or should I say: abandoning the old and crippled along the path?

So, without going into a lot of background research about the decision-making process and the communication between the relevant groups, in a nutshell, this is what likely happened:

Somebody decided to take the (allegedly) obsolete OSS modules out of Ubuntu 10+, and whoever maintains amixer and mute didn't get the memo - nor did the guys maintaining oss-compat or a number of other packages. Also nobody bothered to check if the removal /dev/mixer and friends  would break anything and take the appropriate action - like notifying the maintainer of the relevant packages and if need be, blacklisting them from release until the problem is fixed.

What's wrong with those guys, can't they communicate? This is the 21st century, people, it's not like you have to rely on mail coaches coming through on treacherous, bandit-ridden roads! Whom did those modules hurt? Well their lack hurts somebody, so I reckon something went wrong there.

OK, no point complaining, less whiney, more fixey.

To my best knowledge and web searching skills, there is currently no trivial way to get those modules short of a custom kernel compile.  A lead to a blacklist file in linux-sound-base didn't yield any results either - whether it's there or not, the result stays the same. Chatting with the guys in #ubuntu-devel on freenode finally yielded something besides heartfelt agreement that it shouldn't be like this either: the hint to use osspd, even if they were their usual grumpy self about it. Installing that instantly got aumix working again in principle - except for the basic functionality of controlling volume output. The reason, as far as I can determine, is that the mixer device provided by osspd affects only programs handled by the osspd-provided emulation, but commands made through it do not distribute up into the "real" sound architecture osspd sits on top - which makes osspd a very poor substitute for a real OSS compatibility layer on top of the sound architecture.

So - how does it all sum up for a bottom line? Realistically speaking, aumix and mute are writeoffs in Ubuntu, together with oss-compat and anything else still depending on OSS architecture. It MAY be possible to get some of it working again by putting in enough work, but again realistically speaking it would probably be more work than to switch to a distro still supporting OSS natively.

Considering the fact that I switched to Ubuntu from Debian originally to get a smoother running distro without so many political snatches, I must say I am not amused. While I agree that sometimes stuff must be phased out to achieve progress, sustainable progress cannot be achieved by trampling any inconvenient stuff underfoot. Smooth running should not be achieved by greasing the brakes. Sometimes (more often actually) I feel more like banging heads together than crying.

As for the practical aspects of the problem, a little more sedding and awking will get equally good results with amixer than with aumix, and eventually, someone will shove a script similar to the one I provided in this article somewhere into the Ubuntu/Debian repos, and we'll have hassle-free muting and unmuting of sound again. Until then you're welcome to stick with me for workarounds.

That's it for today, as always, thanks for reading and have fun.

No comments:

Post a Comment