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

Alex Stone alextone1099 at gmail.com
Fri Feb 8 12:22:00 UTC 2013

On 8 February 2013 02:02, Fons Adriaensen <fons at linuxaudio.org> wrote:

> On Thu, Feb 07, 2013 at 04:25:19PM -0800, Michael Bechard wrote:
> > > Counter-counter question: why not try and run MS Office, Outlook,
> > > etc. under Linux ? More choice for the user !
> > Yep, that would be pretty cool. Difficult, but cool. Does that mean
> > it's not worth putting effort into?
> It's wasted effort. Just run those things under the system they were
> designed for. Use a VM if you don't want to waste any hardware.
> > > Any anyway, of those 'tons' maybe 1% provides 'quality', the rest
> > > isn't any better than what we already have or could have natively.
> >
> > Reeeeaaallly debatable...
> Could be.
> At the place where I work we also have a MAC which has 'a ton' of
> Waves plugins available in either Logic or PT. Waves is a *very*
> respected name, they don't produce crap, on the contrary all their
> stuff works and works quite well.
> But do you really think that when doing a mix, the quality of the
> final result will depend on which of the 15 or so general purpose
> equalisers you use on any particular track ? It doesn't - you could
> as well believe in the wonders of unobtainium cables filled with left
> twisting electrons and hand woven by Yorkshire virgins. The result
> will depend only on your skill in using any one of those EQs. Same
> for most other standard plugin functions. A few of them do something
> really unique, that's the 1% I referred to.
> Ciao,
> --
> FA
> A world of exhaustive, reliable metadata would be an utopia.
> It's also a pipe-dream, founded on self-delusion, nerd hubris
> and hysterically inflated market opportunities. (Cory Doctorow)
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

There are differences between the win and mac way of doing things, and the
"collective of smaller parts" philosophy of Linux Audio. This requires a
different mindset. The notion of sessions is much less apparent in the more
monolithic commercial world, and imho, far more important in ours. Male and
Fons are both right, imho, that we don't need to chase tails, but i will
add that a common agreement and enthusiasm for a "LinuxAudio session
protocol", AND a dumb user (count me in)  session interface would go quite
some way to unifying disparate elements, and make linux audio more
presentable to users. User expectations are as excessive in win and mac as
they are in linuxaudio, so i don't think that's a viable reason for debate.
(generally) User input to devs is important, as i've discovered. YMMV for
response, but that's just as true for dealing with commercial vendors,
where the user is far more likely to encounter the "corporate wall of
silence" when asking those companies to fix bugs in their latest grope in
the consumer's wallet.

Personally, i don't care about VSTs or AUs, and i had just as much trouble
with them in the past, as i've had problems with the rapidly developing LV2
format. (And this is 2 allegedly "stable" protocols, versus one growing
before our very eyes. VST and AU were just as problematic in the beginning,
and took quite a bit longer to mature) We have a good collection of plugs,
and rather than push and push for thousands, i'd like to see great plugs of
high quality (which we have some of already) even if this means i have 8
favourites, and "only" 258 others. (Irony noted i hope)

Users need to put up or shut up, and i say that as a user who's had to
learn the "linux way" over some years, when interacting with devs, making
plenty of mistakes along the way. I continue to live and learn.

Good bug reports, well thought out and detailed feature requests (which may
or may not be accepted) to give the devs a clearer idea of what you're
actually trying to say, and some sort of contribution in writing docs,
making vidoes, and/or relentless testing, etc, go a long way. Quality
control is not just the province of devs, but users too, and frankly, if
you as a user finds a problem and doesn't report it, then you deserve what
you get. Whether the dev is interested in your reports or not is up to the
dev, but it's likely that a persistently unreceptive dev will find out soon
enough that bleating about a lack of user interest will fall on deaf ears.
It works both ways here, with the proviso that devs are coding in their own
time, and users are testing and reporting in their own time as well.

Likewise, and i think Fons is right here, if a project is dying, and
there's little to no user interest, then let it die. I'd rather see the
very few devs we have working on live stuff, with regular user input, than
dragging a dead horse to a brothel. Example, i was enthusiastic about using
Rezound but it hasn't built here for some time. At first i was keen to see
it revived by "someone" but learned quickly that my perception of what i
thought was an important linuxaudio app, was in fact just my perception, so
i moved on. Such is life, and part of the rolling evolution.

I don't think we're in as bad shape as is implied in some posts, but the
incomplete or evolving session management required to manipulate our
modular by design collection of apps, coupled with what seems like a
universally accepted concern about hardware drivers do contribute, imho, to
a often exaggerated perception that linux audio is perpetually poor.

A new robust and persistent client name system for jack would be good too.
(in relation to opening the same app more than once in a single session,
and having each instance, plus its presets and settings saved and named the
same way for each session instance) Maybe an addition to the API?

My two Kr.s worth.

Fons, there are no virgins in Yorkshire.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130208/9a7c967c/attachment.html>

More information about the Linux-audio-dev mailing list