Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forward?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: J. Liles <malnourite@...>
Cc: linux-audio-user <linux-audio-user@...>, Linux Audio Developers <linux-audio-dev@...>
Date: Wednesday, October 10, 2012 - 6:37 pm

--f46d0401fb65fa3faf04cbb8bc8e
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 10, 2012 at 2:04 PM, J. Liles wrote:

> [ ... ] but that's understandable considering that most Linux Audio

[ ... ]

> My personal frustration with Linux Audio is mainly focused on the

see your quote above. here's the process:

* people identify an issue with the JACK API
* there is discussion of various approaches to the issue
* one or more people propose actual coded solutions
* there is more discussion
* potentially, one or more of the coded solutions is modified, followed
by more discussion
* if no solution rises to the top, the issue remains unaltered
* if a solution rises to the top, AND if there is a clear consensus that
its the right solution,
then it goes in. this final step is the only one where my role as
"benign dictator" kicks in
since its typically me who decides whether the solution has
emerged and whether there
is broad consensus.

lets look at the situation with MIDI sysex messages for example. the lack
of support for arbitrary length messages is a genuine and real issue,
though doesn't affect the overwhelmingly common uses of JACK MIDI. it has
been discussed extensively. there have been 2 coded solutions proposed.
despite this, i don't feel that there is really a consensus that either of
them is really "right". as a result, the issue remains outstanding. people
are free to challenge this decision based on disagreeing with my assessment
of any of the steps outlined above. you could insist, for example, that
there is a consensus. you could even insist that its silly to go for
consensus when so few people would use or even care about the nature of the
solution. i'm open to all of that, except that i want to see a
meta-consensus in that latter case (i.e. a consensus that no consensus is
OK for this particular issue).

there are many areas where the JACK API could use some work. the only one
that i am aware of where there is reasonable consensus is the port metadata
API, which has not been implemented purely because of the reasons outlined
in your initial line above.

(such improvements are unnecessary for monolithic applications such as

actually, no. Ardour has only recently started "duplicating" any of this
functionality internally, and even then, its for very limited purposes. it
uses JACK for more or less everything, and does not duplicate much of
JACK's functionality at all. Ardour2 continues to use JACK for all audio
routing, for example.

> If an API is going to be fixed and rigid, it must also be extensible (like

that doesn't seem to have held back a bazillion other APIs, including at
least 2 other "notable" (non-free) audio plugin APIs. neither VST nor
CoreAudio are extensible, but this does not appear to have held back
hundreds of plugin developers from creating plugins for those APIs. if
we're looking for reasons why plugin developers do not develop (as a rule)
for Linux, i think that the extensibility or non-extensibility of an API is
probably not the place we'll find the answer(s).

--f46d0401fb65fa3faf04cbb8bc8e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2012 at 2:04 PM, J. Lile=
s <malnourite@gmail.com> wrote:=A0
=A0[ ... ] but that's understandable considering that most Linux Audio =
programs are maintained by single developers (with lots of other projects) =
or small groups.=A0[ ... ]=A0
My personal frustration with Linux Audio is=
mainly focused on the seemlingly iron-clad (but flawed) JACK API. We'v=
e needed the ability to rename clients and have ports with arbitrary event =
payloads (to allow MIDI, OSC, or whatever other streams to be managed via t=
he JACK connection graph and frame clock) for years. And, even though many =
proposals have been made and patches submitted, it doesn't look like th=
e JACK API is ever going to be improved--which doesn't speak well at al=
l for the future of modular audio on Linux
see your quote above. here's the process:=A0=A0 * people identify an issue with the JACK API=A0=A0 * there=
is discussion of various approaches to the issue=A0=A0 * one or more p=
eople propose actual coded solutions
=A0=A0 * there is more discussion=A0=A0 * potentially, one or more of t=
he coded solutions is modified, followed by more discussion=A0=A0 * if =
no solution rises to the top, the issue remains unaltered=A0=A0 * if a =
solution rises to the top, AND if there is a clear consensus that its the r=
ight solution,
=A0=A0=A0=A0=A0=A0=A0=A0 then it goes in. this final step is the only one w=
here my role as "benign dictator" kicks in=A0=A0=A0=A0=A0=A0=
=A0=A0 since its typically me who decides whether the solution has emerged =
and whether there=A0=A0=A0=A0=A0=A0=A0=A0 is broad consensus.
lets look at the situation with MIDI sysex messages for example. the la=
ck of support for arbitrary length messages is a genuine and real issue, th=
ough doesn't affect the overwhelmingly common uses of JACK MIDI. it has=
been discussed extensively. there have been 2 coded solutions proposed. de=
spite this, i don't feel that there is really a consensus that either o=
f them is really "right". as a result, the issue remains outstand=
ing. people are free to challenge this decision based on disagreeing with m=
y assessment of any of the steps outlined above. you could insist, for exam=
ple, that there is a consensus. you could even insist that its silly to go =
for consensus when so few people would use or even care about the nature of=
the solution. i'm open to all of that, except that i want to see a met=
a-consensus in that latter case (i.e. a consensus that no consensus is OK f=
or this particular issue).
there are many areas where the JACK API could use some work. the only o=
ne that i am aware of where there is reasonable consensus is the port metad=
ata API, which has not been implemented purely because of the reasons outli=
ned in your initial line above.
(=
such improvements are unnecessary for monolithic applications such as Ardou=
r since they duplicate all this functionality internally) .
actually, no. Ardour has only recently started =
"duplicating" any of this functionality internally, and even then=
, its for very limited purposes. it uses JACK for more or less everything, =
and does not duplicate much of JACK's functionality at all. Ardour2 con=
tinues to use JACK for all audio routing, for example.
=A0If =
an API is going to be fixed and rigid, it must also be extensible (like LV2=
).
=A0that doesn't seem to have held bac=
k a bazillion other APIs, including at least 2 other "notable" (n=
on-free) audio plugin APIs. neither VST nor CoreAudio are extensible, but t=
his does not appear to have held back hundreds of plugin developers from cr=
eating plugins for those APIs. if we're looking for reasons why plugin =
developers do not develop (as a rule) for Linux, i think that the extensibi=
lity or non-extensibility of an API is probably not the place we'll fin=
d the answer(s).

--f46d0401fb65fa3faf04cbb8bc8e--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Linux Audio 2012: Is Linux Audio moving forward?, Louigi Verona, (Wed Oct 10, 8:24 am)
Re: [LAD] Linux Audio 2012: Is Linux Audio moving forward?, Dominique Michel, (Thu Oct 11, 4:13 pm)
Re: [LAD] Linux Audio 2012: Is Linux Audio moving forward?, M. Edward (Ed) Borasky, (Wed Oct 10, 8:40 pm)
Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forw..., Paul Davis, (Wed Oct 10, 6:37 pm)