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.

aumix and mute not working on Ubuntu 10.10+

As I wrote elsewhere, some dunce decided we didn't need /dev/dsp et al any more and failed to notice that several utilities depend on those files being available, among them aumix and mute.

That means among others that my nifty, shiny volume bars described in this post are no longer working. I'm working on a permanent fix, but for now, to replace mute just use this script:
if [ -e $HOME/.mute-save ] ; then #muted
        amixer sset Master,0 $(cat $HOME/.mute-save) #restore
        rm -f $HOME/.mute-save #and delete the storage
else #not muted
        echo $(amixer sget Master,0|egrep 'Playback[[:space:]]+[0-9]+[[:space:]]+\['\
        |sed -r -e 's/.*Playback[[:space:]]+([0-9]+)[[:space:]]+\[.*/\1/') > $HOME/.mute-save #dissect the amixer output and save it
        amixer sset Master,0 0 #and mute
exit 0
Please excuse if I don't go over it line by line today but I've had a bad day so far and it don't look to be getting better. It's a hack, and it's not so different from the original mute script Just the gist of it: the egrep call makes sure we select the right line from the output and the sed call dissects the actual numeric volume value from it. That's all for today folks, enjoy and have a nicer day than me.

Tuesday, March 5, 2013

Coloring comments in Vi/Vim in readable colors

Just a quick one today: Many people like me - read: traditionalists - like their terminals white-on-black. Today, whether you want it or not, you get saddled with pretty, pretty coloring in vim, ls, whatnot... with the small downside that they tend to assume you are using a white background. My eye doctor thinks dark blue writ on black background is a wonderful idea - so does my optometrist. Small wonder, they make money on selling eyeglasses. Small wonder, I disagree with them there - for some reason I treasure my 25/20ies. If you do as well, the most obvious solution is a :syntax off in vim. Which is, truth to tell, far from the best. What few people know, vim actually comes prepared for black backgrounds - that is just disabled in most distros.

Here's how to change that: open /etc/vim/vimrc and uncomment (or add, for that matter) the following line:

set background=dark
Save, start another vim, enjoy your new-found eye-strain-free syntax coloring

That's all for now. Don't worry, I'm going to make this post pretty later ;)