Re: [arch-general] Audio on Linux, was: We have lost the desktop war. The reason? Windows 7.

On Mon, Oct 26, 2009 at 12:43 PM, wrote:

On Mon, 26 Oct 2009 10:40:44 -0500 Aaron Griffin wrote:

...

On Mon, Oct 26, 2009 at 9:01 AM,   wrote:

...

Conclusion: Yeah, great, install xorg for a minimal graphical desktop, what you get is console-kit, for a minor feature in a monster DE. When will "Desktop" people start to see that they are being intrusive? They live in their own small bubble called GNOME or KDE and can't ever imagine anyone not wanting to use this. Sorry for this "slightly" off topic rant, but it annoys me on a regular basis when I see applications depend on gnome or kde, mostly for some stupid reason called 'integration' which really isn't of much use in the specific DE they integrate with and a hindrance to everyone who's not running exactly that DE.

So please, next time you call something integration, think beyond the bubble. In our little Linux world with limited developer time we need real integration, real solutions and still freedom of choice.

You read my mind. I was debating adding a little rant here about the necessity of hal, consolekit, policykit, devicekit, whatever-the-hellkit to do the stupidest things. It's real counter-intuitive. And don't even get me started about linux audio - apparently the core market for linux audio developers are people doing live, realtime, studio recordings with a line-in jack on a laptop[1] - not the people who just want their machine to beep at them.

I absolutely positively hate that all this shit is getting integrated into the lower level portions of the operating environment. The xorg/hal coupling is gross and disgusting if you don't want or need hal. Soon enough, I'll bet udev and devicekit are going to require each other. When this starts to happen, it's time to stop using this crap

1: Paraphrasing cactus here

As it happens I'm involved in Linux Audio, and I think you're right, most developers are working on applications for what is often called "Pro Audio", basically audio production in contrast to consumption. Those on the consumption side always seem to work on yet another itunes clone.

It's really two worlds. I've been involved in this for years, mostly as user/tester, and don't even know how to set anything up an .asoundrc, I don't even have one. The production world 'speaks' almost exclusively JACK, which uses alsa and oss (and drivers for firewire devices) to talk to hardware. It's great at what it does, but it's not a general purpose soundserver.

I'm not quite sure to what part of the mess you're referring to, so I'll just give you my view of things.

On the lowest level, talking to hardware, is alsa and oss, whereas oss has few users (Arch Linux seems to be an exception). The main benefit of oss seems to be that it's easier to program to, but it's not quite as powerful and supports less hardware. Alsa seems to be hard to program to, lacking documentation, etc.. I often read recommendations to not write for alsa directly, it seems to be hard to get it right.

To make it easy for programmers to output the "klick" they want when clicking a button, abstractions were invented. Lots of them. Everyone can name a few, esd, artsd, whatever. The problem with abstraction is that it's rarely perfect (btw., I love this article about abstraction, I see those problems everywhere: http://www.joelonsoftware.com/articles/LeakyAbstractions.html). If you have a problem the fault can now be the abstraction layer or alsa (in addition to anything below or above). It's basically added complexity through imperfect abstraction. And a zillion different soundservers.

And what comes to the rescue? PulseAudio. Yet another soundserver that tries to abstract away the difference between the zillion soundservers and applications talking to alsa/oss and then talks to the hardware through alsa. It's right in the middle of everything (redhat people seem to like that). Unfortunately it seems to also rely on consolekit, hal, policykit, ... you name it (because redhat people like that too). I experienced it when I was still on ubuntu, which was an (too) early adopter. The experience was quite bad, but I heard it got better since then.

But honestly, I can see the mess, and from what I know I'd say the problem stems from alsa being too difficult to use. The alsa developers hide (from a bombardment of user questions) and no one feels up to the task of really resolving the mess.

I feel more cranky about the plethora of options and the fact that they all work differently with no real choice. You install app foo that uses JACK, great now you need jack installed and running, but your other app, bar, uses raw alsa, so now you have to fiddle with settings in multiple places. It's just so tedious and confusing. Perhaps you are right that this whole thing comes down to alsa sucking.