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

On Feb 5, 2013, at 09:58 14, Dave Phillips wrote: 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: These are not problems with the development space so much as with user expectations (but see more below). Don't care, as these are irrelevant to broadcast automation. These are real issues, especially the second. "With great power comes great responsibility." 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 | |-------------------------------------------------------------------------|