Re: [LAU] [LAA] [ANN] jack-keyboard 2.5 - Linux-audio-user

21 May 2008

On Tuesday 20 May 2008, Nedko Arnaudov wrote:
...
  Florian Schmidt &lt;mista.tapas(a)gmx.net&gt; 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