If you’re not an experienced computer geek with scads of free time on your hands, just stay as far away from Linux as you can. All the openness in the world will not buy back the hours lost in frustration and doubt, as you attempt to do even the simplest of tasks.

I just spent the last two days fighting with Ubuntu’s sound support. If you’re not a Linux gearhead, you’ll probably be surprised – nay astonished! – to learn that there’s no freakin’ way to easily configure your sound card. This process still involves firing up your favorite text editor, pummeling Google for How-To’s, and duking it out with 70s-era computer philosophy over who bears the burden of peripheral configuration, the user or the operating system. Things haven’t changed much since the Slackware 1.0 days.

Case in point: Running MythTV on a Ubuntu box. Result: “/dev/dsp cannot be initialized: device or resource in use, Sound Disabled”. This is still an issue in 2006? Even using the ultrahypermodern advanced ALSA drivers? I guess ALSA’s intended for use in single-user, single-tasking multimedia appliances such as iPods rather than Linux. Which is a shame, considering it’s made specifically for Linux!

Fact is, the user should never have to worry about sound card locking. There are no data integrity issues with a user hearing more than one sound at a time; the human ear is made for that, so sound card-locking should be considered a bug. The OS should queue up the requests for the driver, which should then schedule them to be sent to the hardware in an orderly manner.

Under Ubuntu Linux today, renowned as the User-Friendly Linux, the default configuration doesn’t enable sharing your sound card among applications. If you’re using KDE with the ARTS server running, a common scenario, and you launch Quake 4 or MythTV or any other program that requires sound, it’ll bomb out with a “device busy” error.

There are workarounds, of course. You can create a down-mixing pseudo-driver in your ~/.asoundrc, if you can stay awake through the 3500-word how-to. This worked for me, at least for a bit. Once I rebooted my computer, my USB webcam’s microphone and mixer had remarkably taken over the Card #0 slot, my USB speakers were Card #1, and my onboard sound had become Card #2. This order changed with every boot, in seemingly random fashion, so it meant I had to manually reassign card numbers in the .asoundrc file. This is also necessary whenever a USB peripheral is plugged in or out.

In addition to its not working, there are some other issues to consider:

It’s user-specific

you have to be root to make it system-wide in the /etc/asoundrc, and, since there’s no configuration utilities to speak of, you’ll be mucking around /etc with a text-editor, a limited knowledge of the subject matter, and an appetite for self-destruction.

It’s fragile

You use card numbers instead of GUIDs. If you’ve got USB sound devices, like speakers or a USB webcam, there’s no predictable way to know which card number which device will have. And, of course, they change when you plug a device in or disconnect it. And they’re different every time you reboot, for whatever ungodly reason.

It’s not automatic

The default configuration for ALSA is that you have a single sound card and mixer that never changes; in addition, it will never be accessed simultaneously by multiple processes. The how-to (linked above) says the following:

NOTE: For ALSA 1.0.9rc2 and higher you don’t need to setup dmix. Dmix is enabled as default for soundcards which don’t support hw mixing.

LIES!

When the operating system detects a sound card, it should automatically configure it to a) work, b) be accessible through an easy-to-use interface, c) be optimally configured for output quality and compatibility, and d) be accessible by multiple programs. For the OS, this should be easy: Set up the values, activate the hardware, and write out state to a configuration file automatically. Ideally, it would also send out a system notification that hardware was added, and the user’s environment could deal with the information as it deems fit.

Linux unfairly places this burden on the user. The OS currently does nothing except load the bare-metal driver for the device, and configure it in a way that makes it almost useless. The existing environments, like KDE and Gnome, offer absolutely no hardware configuration interfaces, and the CLI offers nothing more than a text-editor and 40 man pages and a pat on the behind for luck. In fact, KDE (and I assume Gnome) compound the problem by loading an outdated “sound server”, ARTS, which provides a lackluster facility simulating concurrent sound-card access with terrible latency, and then only for programs specifically written for ARTS.

For the record, I have never had a problem with this under Mac OS X, BeOS, or any Windows since 95. In fact, the only weirdness I’ve had under OS X is with the Videolan client. Sticking to its Open Source roots of user hatred and bad interface design, it makes the user put in a sound card “number” to play sound through external USB speakers. No drop-downs, no sanity checks*, and no hint as to which number belongs to which card. Pathetic.

* - If you configure it to use the second sound device, for example, it will still attempt to use it even after it’s been removed, and there no longer is a second device.