On Tuesday 20 May 2008, Nedko Arnaudov wrote: > Florian Schmidt <mista.tapas@xxxxxxx> 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
