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

[hollunder at gmx.at]

On Mon, 26 Oct 2009 10:40:44 -0500
Aaron Griffin <aaronmgriffin at gmail.com> wrote:

> On Mon, Oct 26, 2009 at 9:01 AM,  <hollunder at gmx.at> 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.

Philipp