[LAU] [LAA] [ANN] jack-keyboard 2.5

[Florian Schmidt]

On Tuesday 20 May 2008, Nedko Arnaudov wrote:
> Florian Schmidt <mista.tapas at gmx.net> writes:
> >> Sure it does.  But what makes ALSA MIDI more suitable for that purpose?
> >
> > Zero added latency for one. jackd only makes sense for inter-process
> > delivery of MIDI signals. For inter-machine sending of midi where the
> > other machine might be a hardware synth, it doesn't make sense at all to
> > send the signal through another daemon..
>
> AFAIK this is just wrong, JACK ALSA MIDI backends are normal ALSA MIDI
> clients, there is nowhere you get additional latency.

Maybe i missed something. Here's how i view things:

Yes, i have an app, let's call it jack-keyboard which can only talk to jackd. 
Ok, the user wants to send MIDI from jack-keyboard to the hardware MIDI  
interface on the computer which is connected to a hardware synthesizer..

Ok, so the user hooks up the jackd MIDI output port of jack-keyboard to the 
respective jackd MIDI input port of the jackd MIDI -> ALSA MIDI bridge. 

Let's further assume that the periodsize of jackd is large (> 100ms).. The 
user presses a key and jack-keyboard writes the MIDI event (timestamped i 
suppose) into its buffer. Then jackd will, at some point in the future, 
decide to run a cycle. The event will propagate to the jackd MIDI - ALSA MIDI 
bridge. The event is timestamped, so the ALSA MIDI bridge when it has put 
emphasis on providing jitter free experience, will wait just a little more 
with sending out the event to the hw interface.

Finally the event is sent out. How is >100ms "no extra delay"? Or does jackd 
also offer a way to "short circuit" the process cycles for events that are 
sent from an app directly to a hw interface?

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org