Linux Audio versus Everything Else

I had a chance yesterday to read Linux Hater’s post about problems with Linux audio drivers and APIs. The post is about pulse audio’s inclusion in Fedora, which led to broken audio for many Fedora users. Like lemmings, other distros decided if it’s good enough for Fedora then it’s good enough for them. Tumbling dominoes…

The issue reminded me of problems I’ve had at various times with applications in Linux. Pulse audio is hardly alone in issues related to Linux audio. One of the things that’s caused me more trouble than it’s worth has been getting mplayer to play nice with ALSA. The mplayer front page says ALSA is supported so I didn’t know what the problem was:

A little background. I hadn’t bothered to use mplayer in Linux at all; I stuck with default apps — typically XMMS, xine, etc. — that shipped with the distros I used. I first started using mplayer in FreeBSD a couple years ago and grew to appreciate it. So much so that I decided to use it when I switched back to using DSL last year. I also installed it in a few other distros I tried on both laptop (before ditching multimedia altogether on it) and desktop.

It had always worked fine in FreeBSD — and also in OpenBSD (which has become my operating system of choice) — but it totally sucked in Linux, especially synching audio and video. I thought it was maybe due to the binary packaging of the distros on which I’d tried it. I decided to compile it myself and got the same wretched results. Then I wondered if my hardware was the problem, but I reinstalled my BSD hard drive and quickly knew that everything was fine in BSD. So I looked for help on the mplayer site to see what the problem was with using it in Linux.

One of the first things I looked at was the following section in the documentation:

Ahh, well, that first sentence certainly clears it all up: “Linux sound card drivers have compatibility problems.” No shit? I’d run into problems before with the OSS driver in DSL playing single-channel audio at double speed. I’d also noticed other anomalies — at least I thought they were anomalous — using ALSA in other distros. Not only that, the problems weren’t always isolated to mplayer. One of the reasons I wanted to use mplayer in DSL was because XMMS was butchering things.

So I had plenty of reason to take the mplayer developers at their word. Things that “just worked” in Solaris, Windows, and the BSDs could be a total abortion in Linux. Different drivers. Solaris and BSD have Sun audio, Linux doesn’t.

The next section notes that ALSA 0.5 has buggy OSS emulation and causes mplayer to crash. That’s not fun.

Yes, both of those documentation sections provide workarounds. They also explain the reasons why workarounds are needed: immature, buggy, and/or shoddily-written drivers and emulation layers. In short, the problem is on the kernel side and not the application side. I know the application “just works” in BSD; I also know it doesn’t in Linux, at least not as it’s supposed to (why should I have to maintain two sets of scripts, one of which only employs workarounds for buggy drivers, to use the same app?).

I’d presumed — quite wrongly — that Linux would have better audio support than the BSDs on the dual grounds that Linux development tends to be more cutting-edge than the BSDs and Linux has been promoted harder as a desktop system. Lesson learned.

the smarter solution

the smarter solution

This isn’t isolated to mplayer and pulse audio, offerings in which users may expect a little imperfection due to the ever-changing nature (or is it chaos?) of open source development. It also affects how things like Flash, which isn’t open source, operate within Linux. Many users fault Adobe for the unpredictable performance (i. e., crashing) of Linux Flash. The problem, which Adobe has pointed out, lies in the diversity of APIs (ALSA versus OSS, which ALSA has won as far as Adobe is concerned) and UI tools in the Linux universe — qt versus GTK+, etc. Things are much easier in a proprietary environment like Windows because the libraries and drivers are unified and homogeneous. Microsoft doesn’t have myriad distributions with unique configurations. What works right for one Linux distro often doesn’t work across the board — something which has been true for a lot of things beyond audio because there’s no standardization.

There are many things Linux does exceptionally well. Audio processing really isn’t one of them. This is one area in which the bazaar isn’t going to supplant the cathedral anytime soon. Where Windows users take audio performance for granted, Linux users take audio bugs for granted. It’s yet another reason I doubt Linux will make a significant dent in Microsoft’s desktop market share.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: