On Wed, Oct 10, 2012 at 2:04 PM, J. Liles <malnourite@email-addr-hidden> wrote:
> [ ... ] but that's understandable considering that most Linux Audio
> programs are maintained by single developers (with lots of other projects)
> or small groups.
>
[ ... ]
> My personal frustration with Linux Audio is mainly focused on the
> seemlingly iron-clad (but flawed) JACK API. We've 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 the JACK connection graph
> and frame clock) for years. And, even though many proposals have been made
> and patches submitted, it doesn't look like the JACK API is ever going to
> be improved--which doesn't speak well at all for the future of modular
> audio on Linux
>
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
> Ardour 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 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
> LV2).
>
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).
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Oct 11 00:15:04 2012
This archive was generated by hypermail 2.1.8 : Thu Oct 11 2012 - 00:15:04 EEST