False Prophets

I have had, ever since I got my current desktop, been frustrated with ALSA support for it. The machine is an Shuttle SN25P (with ice1724 onboard 7.1 sound card); it’s otherwise very nice. I’ve had it for a bit over a year. When I got it, I lost several long weekends to hacking on ALSA and peering through asoundrc files, gstreamer and gnome-control-center source code, and other such things.

There were two basic problems. One was that no matter what I did, I couldn’t get the back speakers to play independent channels. Generally they mirrored the front speakers. The other was they adjusted volume based on the headphone mixer, rather than the master mixer - especially aggravating because muting the master mixer left my music still pouring out of the rear speakers! I filed a bug in the ALSA tracker, but didn’t get much feedback, and eventually gave up.

Last week, someone else seconded the bug. A helpful fellow responded and pointed us to a couple of basics, like the ALSA datasheet archive (very handy, since as far as I can tell a lot of them aren’t available elsewhere, at least without NDAs). We spent some time poring over those. One of the interesting things I learned this weekend: there’s a bunch of independent chips involved in onboard sound, in my case three. One seems to do communication between the computer and the analog-digital convertor, another handles the actual conversion (AC97 compatible in this case), and a third (I think…) handles the remaining two channels for 7.1 support since the second one only seems to do six.

Digression time. Unfortunately one of the things he asked us to check was physical connections between the chips, and whether there was an onboard EEPROM… and somehow, in lightly applying enough compressed air to dislodge the dust, I got something wedged into the fan of my video card. Which began making a horrible rattling noise. And then when I attempted to clean it, I made it even worse. So at this point in my Saturday afternoon I had to go out and buy another one. The new one is marginally crappier than the old one, which was also pretty cheap, but the new one has the advantage of not needing a fan at all.

Digression part two. While I was at the store, I picked up a Slug. I haven’t unboxed it yet or gotten a drive for it, but I think I will in a week or two, and see if I can pick up some of Martin’s excellent work in running Debian on one. I see that the IXP ethernet driver isn’t working at the moment, maybe I can give Lennert a hand…

At this point it was clear ALSA had eaten my weekend. So I came back to finish the job. The other reporter of the bug noticed a very interesting bit in the manual for the VT1617A (Via-manufactured AC97 codec) - which affected volume control and routing for the rear surround channels. I poked around in the kernel driver for a while, and discovered that the similar VT1616 chip exposed that bit as an ALSA mixer control (boolean switch)! So, wiring the two together was the next logical step. And suddenly I’d made a world of progress. I could hear things out the back speakers.

Apparently - as far as I can tell anyway - no one has good solutions to this problem. I fumbled around with it for a while, wrote two more ALSA patches, and got manual configuration to use a software volume control (the “softvol” plugin) and mute switch which govern all channels. But I’m taking a break from that while I fish around for how this works on other chipsets. It’s so immensely awkward that I can’t believe there’s no standard solution. I mean, is wanting your volume control to affect all your speakers such a rare thing? Anyway, this paragraph summarizes about six hours of beating my head on the wall. Most of this was at the asoundrc format, which is immensely picky, underdocumented, and seems like it really oughtn’t to be needed at all. But apparently it is.

During the course of this I got to learn how different applications decide which volume control to use, which was exciting in an exasperating and insanity inducing sort of way. You see, ALSA exports basically everything on the card as a “mixer control”. There’s some things which recognize volume controls by name, and some basic sorting by usefulness. xmms allows you to select any one control to use for its volume slider, which is nice. The GNOME mixer applet allows you to select any arbitrary _set_ of volume controls for the panel applet, which is even nicer. But it’s at this point that, both last time and this time, I gave up in general rage. You see, the mixer applet is completely disconnected from the other and more useful way I deal with volume - the hotkeys on my keyboard, which GNOME also handles. But those go to gnome-settings-daemon, and a bunch of code labelled “acme”.

And this just adjusts the volume on the track which gstreamer (the GNOME audio management libraries) have marked as “MASTER”, and that’s done based on the order ALSA supplies the controls, which is done by a name-based sorting deep within the bowels of the ALSA library (it’s in mixer/simple_none.c). And if you have two with similar enough names, it slaves them together. And nothing has a higher priority than the hardware supplied “Master Playback” controls. The best I could manage was to get the software volume control listed right after the master (in which case it wouldn’t get adjusted at all), or adjusted in lockstep with the real master channel (which causes the front speakers to drop at a different rate from the rear speakers, messing up depth).

Like last time, this was the point at which I gave up for the weekend. But this time I’ve learned a lot more and made a whole lot more progress! And written more of it down, so hopefully I have to rediscover less of it next time. I really was going to do a bunch of other things this weekend… but it just didn’t happen.