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

[Aaron Griffin]

On Mon, Oct 26, 2009 at 12:43 PM,  <hollunder at gmx.at> wrote:
> 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.

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.