ubuntu – 'pataprogramming

Ever since installing Karmic on my main box, audio has been an intermittent annoyance. While I like the idea behind pulseaudio, its presence in Karmic has certainly has contributed to a few headaches (made painfully worse when I imprudently tried exploring the network multicast features). I’ve had most of the bugs worked out for a while, except for one: before a sound is played back, a loud, unpleasant, sharp crack is emitted by the speakers. After that, sound playback proceeds normally…music, further OS alert beeps, no problem. However, after a period of idleness without any sound activity (ten seconds, in fact), the next speaker access will result in the same loud report. Even though annoying, this problem has not been critical.

The box is custom-built system based around an Asus P6T motherboard, which has has an onboard RealTek ALC1200 for sound. This shows up in Linux as

00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family)
HD Audio Controller

and thus uses the snd_hda_intel kernel module (Intel High-Definition Audio).

Having just had occasion to look into my /etc/modprobe.d/alsa-base.conf, I found this exceedingly suspicious pair of lines:

# Power down HDA controllers after 10 idle seconds
options snd-hda-intel power_save=10 power_save_controller=N

The 10-second time-out surely could not be a coincidence.

Sure enough, commenting it out has removed this lingering audio annoyance (which turns out to be completely unrelated to pulse). It appears this issue is already known: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/417302. As one commenter observed: “I was also affected by this. I think this is a bug – speakers should not produce unpleasant sounds for [no] apparent reason.” This is a sentiment with which I can only agree.

On the way into Philadelphia today, my train was delayed. While the rain seemed rather pleasant as I walked to the station, the winds had been strong enough to disrupt service. An earlier train had been disabled on the line, blocking the tracks. In all, it made for a thoroughly tedious experience, and not one to encourage me in my attempts to use public transit nor bolster my (non-existent) love for SEPTA.

Eventually, a “rescue train” came along to extract we poor passengers from our misery. The extraction was not timely, and rather than arriving forty-five minutes early for the lecture on a multi-robot planning, I arrived forty-five minutes late: just in time to miss the end.

You can imagine I was quite pleased, then, when a friend told me the video would be available online. Unfortunately, the link he sent me was for a lecture earlier in the month. Even more distressingly, the recording was only provided via Microsoft Silverlight. I simply do not understand why a computer science department that runs mostly on Linux keeps returning to suckle at a Windows-only, proprietary teat. Disgruntled, I made a note to check out Moonlight at some point.

Somewhat later, I ran an apt-cache search moonlight on my main research box (currently on Karmic), and sure enough, moonlight-plugin-mozilla looked plenty promising. A simple sudo aptitude install moonlight-plugin-mozilla, and it was on its way.

I returned to writing email. A few minutes later, I heard the sound of talking: a video was playing somewhere. Irritated, I tried to figure out if a video one of my open tabs had launched itself. I was somewhat gobsmacked when I found it was the lecture mentioned above: unless I somehow managed to restart Firefox in a memoryless stupor, it seems that the Moonlight plugin insinuated itself into a running Firefox 3.5.7 instance, loaded the player, and kicked off the playback without any intervention. Impressively smooth and simple.

This may partially make up for my annoyance with Karmic’s compiz, which has an annoying habit of dying out from under X every day or two.