[LAD] Jack port alias names

Paul Davis paul at linuxaudiosystems.com
Tue Feb 23 00:50:35 UTC 2010

On Mon, Feb 22, 2010 at 6:11 PM,  <fons at kokkinizita.net> wrote:
> On Mon, Feb 22, 2010 at 06:06:55PM -0500, Paul Davis wrote:
>> >> But why is your app giving midi-ports both for jack and
>> >> alsa at the same time?
>> >
>> > Why not?  I think that doing this actually serves users
>> > better, especially since JACK MIDI adoption is still on the
>> > up-swing.
>> 1) it makes the app quite a bit more complex
>> 2) it introduces yet another name mapping scheme from ALSA<->JACK
>> 3) its a job best left for specialized clients like a2jmidid
>> 4) it makes it harder to write an app that can be used with or without JACK
> Aeolus also provides both when used in Jack mode.
> As regards (1), it's mainly the Jack interface that
> complicates things as many of the MIDI messages can't
> be handled in the process callback.

my experience with ardour3 tells me this: JACK MIDI and ALSA MIDI are
opposites in this respect:

* ALSA MIDI is fundamentally poor for realtime MIDI driven synthesis
and parameter control BUT very convenient for system control
* JACK MIDI is very inconvenient for system control but fundamentally
good for realtime MIDI driven synthesis and parameter control

we've adopted some relatively simple designs in a3 that make JACK MIDI
ports *not* being used for RT synthesis etc look (API-wise) pretty
much like an ALSA MIDI port (by interposing a FIFO between the process
callback and everything else)

i don't really see too many ways out of this dilemma. injecting
information into a JACK client (or any piece of software really) that
is intended for use in an RT-constrained piece of code is really so
different than injecting it for non-RT purposes that i don't think
there is a way to just get the best of both worlds with no effort.


More information about the Linux-audio-dev mailing list