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 ste
ak 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 |
|-------------------------------------------------------------------------|
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
