[LAD] So what do you think sucks about Linux audio ?

[Fred Gleason]

On Feb 5, 2013, at 09:58 14, Dave Phillips wrote:

> I've been reading a lot of negative (read: vitriolic) commentary about the world of Linux audio development and applications. I won't bother to say where, just "the usual places" will have to suffice. Of greater interest to me is the commentary itself - it seems to boil down to the following plaints and lamentations (in no particular order) :

As someone who primarily addresses a very specialized subset of pro-audio users (professional radio broadcasters), here is my (admittedly parochial) take on your list of complaints:


> Too many distros.
> Too many audio-optimized distros.
> Too many unstable/unfinished applications.
> Too many  "standards" (esp. wrt plugins).
> Confusion re: desktops, and GUI toolkits.

These are not problems with the development space so much as with user expectations (but see more below).


> Not enough native plugins, esp. instruments.
> Inconsistent support for VST/VSTi plugins.
> Poor support for certain modes of composition (think Ableton Live).

Don't care, as these are irrelevant to broadcast automation.


> Poor external/internal session management.
> Lack of support for contemporary hardware.

These are real issues, especially the second.


> Too difficult to set up audio system.
> JACK is a pain.

"With great power comes great responsibility."


> Too much conflict/fragmentation within the development community.

And here I suspect is the central misconception.  The notion of "the development community" is a misnomer.  In fact, what we have are "development communities" (plural).  A real world example may help:  Here on LAD I see lots of discussion about design and development for what I have come to term the "Music Production Model".  There are several assumptions baked into this model, such as that of a "session" that has a lifetime on the order of several hours, following which the whole thing is torn down and put away until the next time.  The system seeks to be as self-contained as possible, with capture, processing, editing and even mastering all being done on the same system ('system' in this sense being understood to include the possibility of multiple hosts working cooperatively).  This in turn entails lots of concern with *internal* modularity (e.g. JACK, plug-ins), but not so much with the external world beyond the basic audio interfaces.

Now come peek over the wall with me into the world of broadcast radio automation.  Two primary drivers exist here that are notably weaker and/or absent in the Music Production Model -- long term reliability, and external interfacing.  Broadcast radio playout systems don't have session lifetimes measured in hours -- weeks or months between application restarts are the norm!  Downtime is not just an inconvenience, but a real cost that can easily run into the thousands per minute.  The system may well be located at a transmitter site on top of a mountain with 1 M of snow in the winter, so you'd better be able to monitor and control it remotely.  Will it interface with all my external systems, such as router consoles, traffic billing systems, RDS / PAD encoders, now-playing website widgets, etc, etc?

Now, please don't get me wrong here.  I'm *not* saying that one set of design goals is somehow  more "legitimate" than another.  What I am saying is that they are *different*, and as such require different designs, different paradigms and hence, quite often, different developers and development communities.  In many of the points in your original list I see an implicit assumption that the goal is One Perfect System that can host every application without compromises.  That's a chimera -- the final application should always drive the choice of tools used to implement it.  And that's the real power of Linux as an audio platform -- configurability!  I suspect that many of the points in your list about "confusion" and "fragmentation" come from users who are expecting this One Perfect System and are then disappointed by the reality of having to make choices and exercise knowledge.  (And, even those Other OSes that purport to deliver this universal platform are more sizzle than steak here, as users who have attempted to configure multiple applications with varying requirements for MME vs. DirectSound vs. ASIO can attest).  Life is complicated.  Linux exposes this and empowers the user to make choices about what fits *his* application best, rather than trying to paper them over into an illusion of homogeneity.  That's a strength, not a weakness!

Cheers!


|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |               Chief Developer               |
|                           |               Paravel Systems               |
|-------------------------------------------------------------------------|
|             The wise man doesn't give the right answers,                |
|             he poses the right questions.                               |
|                                         -- Claude Levi-Strauss          |
|-------------------------------------------------------------------------|