Now, there are two things that mean you “really need to” hit the disc: reading data that isn’t already cached (duh), and the fsync() and fdatasync() calls. The latter are requests by an application to ensure that all of the data written to far has hit the disc, and they cause the disk to spin up in laptop mode.

Unfortunately, Firefox has a habit of randomly issuing fdatasync() calls. It does this as part of the SQLite backend for its various databases (especially places.sqlite), in order to avoid data corruption. Now, data corruption isn’t terribly likely on a laptop with a battery (which is essentially a built-in UPS), so this is a terrible annoyance with little benefit anyway. There has been talk about this problem, but apparently it’s still around (and the toolkit.storage.synchronous about:config property didn’t work for me). Most of the reports appear to claim that this happens while browsing, but I’ve seen it happen periodically even when Firefox is left idle. Maybe it’s caused by some extension or AJAX webapp? Who knows.

Ideally this problem would be fixed in laptop_mode itself, but that doesn’t appear to be the case and I’m not going to poke this part of my kernel just yet, so here’s a simpler userspace solution: we can preload a library into Firefox that intercepts fsync() and fdatasync() and ignores them. Even better, we can make it do that only if we’re in laptop_mode. All it takes is a little C code:

#define _GNU_SOURCE
#include <unistd.h>
#include <dlfcn.h>
#include <sys/stat.h>
#include <fcntl.h>

static int in_laptop_mode(void)
{
	char buf[2];
	int fd;
	int l;
	fd = open("/proc/sys/vm/laptop_mode", O_RDONLY);
	if (fd < 0)
		return 0;
	l = read(fd, buf, 2);
	close(fd);
	if (l == 2 && buf[0] == '0' && buf[1] == '\n')
		return 0;
	else
		return 1;
}

int fsync(int fd)
{
	static int (*_fsync)(int);
	if (!_fsync)
		_fsync = dlsym(RTLD_NEXT, "fsync");
	if (!in_laptop_mode())
		return _fsync(fd);
	else
		return 0;
}

int fdatasync(int fd)
{
	static int (*_fdatasync)(int);
	if (!_fdatasync)
		_fdatasync = dlsym(RTLD_NEXT, "fdatasync");
	if (!in_laptop_mode())
		return _fdatasync(fd);
	else
		return 0;
}

To compile and use it:

$ gcc -O2 -Wall -shared -fPIC -o killsync.so killsync.c -ldl
$ LD_PRELOAD=`pwd`/killsync.so firefox

Et voilà, firefox no longer wakes up the hard drive(s). You can confirm that the fsync/fdatasync calls no longer make it to the kernel by running strace -f -p `pidof firefox`, but only in laptop_mode.

I’ve been typing this blog post with this hack applied and so far HDD spinups have been few, far in between, and fairly short. I still have a few offenders to nail (mostly KDE related), but Firefox was one of the worst ones and it’s now history. PowerTOP says I’m saving 3-4W of power. Huzzah! Now I just need to get a kernel with timer stats built so I can fix my insane wakeups-from-idle per second…

This laptop is peculiar because it has built-in “5.1″ audio. Yes, it does really have 6 speakers, though you’d be hard pressed to get much spatial separation out of them (and they aren’t even placed around symmetrically). However, the speakers do end up making a very decent multiway audio system, by laptop standards: the “rear” pair (which is actually between the keyboard and the screen; the mind boggles) is good with the high end, the “front” and center speakers (front edge of the laptop) are your average mediocre speakers that can handle mid-end, and the “Tuba” not-so-”sub” woofer fills in enough low-end to equal a decent overall speaker, although of course with zero stereo/spatial separation since there’s only one of it (actual subwoofers can pull off mono because the human ear can’t really hear spatial position at low frequencies, but the Tuba is more like the only non-sucky speaker in the entire laptop).

What this boils down to is that you really want good audio support for all 6 speakers if you want to take advantage of the audio capabilities at all. Most importantly, stereo needs to be upmixed and a good portion of the normal audio needs to be routed to the Tuba. ALSA’s asound.conf makes this easy, assuming the actual hardware works fine. Of course, that’s not the case.

This thing uses (of course) Intel HDA audio with a Realtek ALC889 codec. This codec is fairly new and support is of course still a bit sketchy. There are two parts to getting things to work: the software needs to know how to talk to the ALC889 codec, and it also needs to know how to configure it to work with the laptop’s hardware design (i.e. how the chip’s outputs connect to the actual speakers and jacks, which varies). After reading up on HDA audio codec specs and looking for examples, the latter part wasn’t very hard. There’s even a tool called hda-analyzer which lets you tweak most HDA configuration on the fly with a nifty GUI. I also rendered a graph (warning: large image) of the codec’s internal audio routing.

Unfortunately, after verifying that I had mapped all of the connections properly and could get individual output through any one of the speakers and audio jacks, I hit a showstopper. The codec has 5 stereo DACs (10 channels total, nominally 7.1 plus an extra stereo connection) but only the first two DACs worked, which gave me 4.0 audio. They rest just appeared to be completely dead. I knew the problem was with the DACs because I could remap the audio outputs to use one of the first two DACs and that worked, and I could tell the first two DACs to play other channels from the input stream and that worked fine too. Audio was getting to the chip, and audio could get out from the chip, but somewhere during the digital-to-analog conversion for DACs 3-5 it was just disappearing. I searched the Realtek datasheet and ALC specs for info on how to turn DACs off or on but found no such thing. Of course, a standard wouldn’t be complete without a mechanism for vendor-specified proprietary extensions (and those standards that don’t have them are abused anyway). HDA has these things called coefficient registers, which is just a dumb name for vendor proprietary registers. ALSA already has some code to tweak these on other Realtek codecs, though nothing related to turning DACs on or off. At this point this was clearly Realtek’s fault for not documenting how to turn on DACs that are turned off by default. So I e-mailed them describing the issue in clear terms, and, in response, got treated like a clueless end-user. They kept sending me patched/modified versions of the realtek support for ALSA with useless changes like support for new laptops and the like and no actual changes to fix the DAC issue. Of course, none of it was helpful, and I gave up on playing along after a couple weeks of wasted time.

Eventually this annoyed me enough that I just desperately tried flipping every bit in every coefficient register. After about 45 minutes of mind-numbing tones (I made a little multichannel test tone using a pentatonic scale which looped a couple thousand times until I was done) I didn’t find the magic bit to turn on the DACs, but I found two registers able to kill the already-working DACs, guessed a bit, and found out that you need to clear both of them to enable the broken DACs. Success.

Long story short, this, along with proper support for the laptop’s hardware and such, should be in the next version of ALSA. If you’re impatient, grab this patch and apply it. The one thing that’s missing is internal mic support (it’s in there but I don’t think it works) – I tried a few things and came up dry, but I don’t really plan on using it anyway. You’ll also want an asound.conf to do the upmixing: this is what I use. Just place it in /etc (back up / merge your distro’s version, if any, before you overwrite it!).

Lastly, if you have another Acer laptop with similar audio capabilities, the code will probably work for you but it won’t autodetect the laptop. You’ll want to use the option “model=acer-aspire-8930g” when loading the snd-hda-intel module to force it. For example, it’s very likely that it will work with the 8920G. If it works, send the output of “lspci -v” or “sudo lspci -v” to me or an ALSA developer so it can be added to the list.

Update: I submitted another patch to fix input issues. This gives you the full 3 capture devices, one of which can capture the internal front microphone (the others can’t; that’s a chip limitation). The microphone is stereo but due to the weird sum/difference format I’ve hacked it to just output mono to the device. The stereo is useless anyway, since the mics are too close together. Grab the patch here.