I’ll eventually write a longer post about how different bits and pieces of this laptop’s hardware fare under Linux. For now, I’ve managed to strike one of the more annoying issues: proper audio. Scroll down if you’re impatient and want the code; read on if you want the full story.
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 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.