[LAU] Is ALSA using hrtimer?

[Niels Mayer]

Many thanks for the explanations. Of course, now I have even more questions :-)

> The issue is not using ALSA MIDI. Its routing from
> JACK to ALSA MIDI. If this is not designed and
> implemented correctly, it can end up with
> large amounts of jitter (variable delays in how long
> it takes to actually deliver MIDI data to its destination).
> a2jmidid (at least relatively recent > versions) is
> correctly designed and implemented in this respect.

Seeking clarification: does this mean the jitter issues affect only
using Jack MIDI ? If I'm just using qjackctl to patch between
different ALSA midi sources, and am not using jack midi at all, then I
won't suffer from the aforementioned jitter issues?

My typical use cases involve patching (via qjackctl) ALSA midi to ALSA
midi such as:
* external midi keyboard --> sequencer (e.g. qtractor or rosegarden)
* sequencer --> external midi synth/sampler
* sequencer or external midi keyboard --> ALSA synth (e.g. yoshimi or qsynth)

In the future, I want to try getting my external MIDI gear to generate
midi clock and attempt to sync jack midi and transport to my external
gear. Is this where I'll run into problems, as I will need to bridge
ALSA midi to Jack midi in order to access the jack transport? What's
the most reliable way of slaving Jackd to an external MIDI clock? (as
opposed to using http://www.teuton.org/~gabriel/jack_midi_clock/
to slave external devices to jack's midi clock).

What are the advantages of using Jack Midi over ALSA midi? Perhaps due
to its newness, I only have one synth that uses jack-midi::
http://ll-plugins.nongnu.org/azr3/ --  Is Jack Midi and a2jmidid the
direction we should be moving towards in the future, and currently
isn't well represented by tools and software because it's newer than
ALSA?

Thanks!

-- Niels.

PS: what happens with ALSA and Jack timing when running a "tickless
kernel": http://kerneltrap.org/node/6750
> "This feature is implemented by driving 'low res timer wheel' processing via
> special per-CPU high-res timers, which timers are
> reprogrammed to the next-low-res-timer-expires interval.
> This tickless-kernel design is SMP-safe in a natural way and has been
> developed on SMP systems from the beginning.