This is the 64-bit version of Ubuntu. There is little point to running down the entire catalogue. Almost everything works Out of the Box® as we have come to expect from Ubuntu. When it doesn’t is when we have something to say. Further, having something to say is often limited to what little we each tend to mess with, so we only know what we use. I’m not a grand testing guru, but I’m sharing this with those who are doing something similar. Nobody here is pretending this is a proper technology review.
The primary big problem is Alsa. Currently, the hardware detection is unable to recognize every pertinent detail. For the impatient — on most recent Inspirons using ICH9 sound chips, edit /etc/modprobe.d/alsa-base.conf by adding the following line to the bottom of the file:
options snd-hda-intel model=6stack-dell
Then reboot. It’s that simple.
For those of you seeking clues to working it out with other machines, the solution means you have do some research, then get your hands dirty with modifying the config files by hand. I assure you it’s worth it. The context is realizing a great many recent onboard chipsets, Intel in particular, are configured in so very many different ways, there is no way to know exactly what does the trick. The details are buried on the Alsa website, and can be gleaned from a hundred different bug reports and forum discussions. A good starting place is this page on the Ubuntu Community documentation website. The critical items start under the heading “Manually Specify Module Parameters”:
- Find the codec used by your chipset. My Inspiron reports “Realtek ALC888”.
- Check the listing of possible model names Alsa uses in your distro bundled documentation. For Ubuntu, that turned out to be
/usr/share/doc/alsa-base/driver/HD-Audio-Models.txt.gz, which was easily read by usingzlessfrom the commandline. - If you cannot identify what’s most plausible for your hardware, start with the “auto” parameter.
- Prepare yourself to keep testing different options until you get something which works properly.
In my case, the primary issue was a small amount of popping in the output, but worst of all, plugging in headphones at the front panel of the tower didn’t cut the main speaker output. Alsa didn’t know which output channel did what until I identified the layout by the model name. Most of the complaints were along the lines of “no headphone jack sense control”. The fix I found does not fix that peculiar problem with the mixer interface, but it did fix the problem automatically.
When testing different distros to find which will work the best, I realize perfection on any particular hardware is unlikely, for the simple reason the developers can’t buy a sample of everything out there. A limited number of glitches, and some do-it-yourself fixes are always acceptable with every OS. Some things are simply too much, or there may be too many little things together. Here is my experience on what I’ve tested so far on this machine:
- CentOS 5 — This would have been my preference. I couldn’t get past the IDE detection, since the installer kept loading the wrong driver first and finding nothing. The IDE driver
ata_piixis unable to read it, and would prevent the AHCI driver from loading. This is a highly debated bug in the RedHat world, and it seems the developers insist the manufacturer is wrong for not including an option in the BIOS for it. They don’t appear to have any interest in fixing it, and it affects Fedora, as well. Nice. - openSUSE 11.1 and 11.2 — Both were afflicted by numerous issues. Aside from the same failure to understand which model was appropriate for the ALSA driver, the instructions for debugging are missing critical steps not obvious to ordinary users trying to figure it out. Their whole approach is different from the Debian world, so the above advice may not help at all. However, there were still a large number of minor flaws which have come to characterize SUSE these days.
- Debian Lenny — The installer could never find my Realtek RTL8101E ethernet port. Without having the full DVD on hand, I would not have gotten enough installed to work out a fix. (I didn’t get around to testing Squeeze.)
- Ubuntu 9.04 — Everything was pretty good, but I kept getting random I/O freezes. I would be typing away on something important and the system would lock up hard. A full reboot was required, and I always lost my work — that’s unforgivable. Something in the way the X server interacted with the hardware was very wrong.
Update: (16 Jan 2010) After having some trouble with Ubuntu 9.10, I ran openSUSE 11.2 for quite a while. However, it just wasn’t quite right, either. So I decided to give Karmic one more try, but this time I installed from a Live-Run session. Apparently this made some sort of difference in how the hardware was configured, because it is working far better than the first time.
