Florian Schmidt writes:
I further assume that the alsa seq event system
is used
This is true of Rosegarden,
and midi events are not queued
for future delivery but always delivered immediately.
but this isn't -- Rosegarden always queues events
from a non-RT thread and lets the ALSA sequencer
kernel layer deliver them. (Thru events are delivered
directly, with potential additional latency because of
the lower priority used for the MIDI thread.) In
principle this should mean that only the priority of
the receiving synth's MIDI thread is significant for
the timing of sequenced events. We also have a
mechanism to compensate for gradual drift between
the MIDI timing source (kernel timers or RTC) and
soundcard clock, when synchronising to audio, by
adjusting the sequencer skew factor. (This happens
to be similar to the mechanism for slaving to MTC,
which is handy.)
In my experience this is all a long way from
foolproof. The most common problems for users
seem to be:
- ALSA sequencer uses kernel timers by default and
of course they only run at 100 or 250Hz in many
kernels.
- ALSA sequencer can sync to RTC, but the
associated module (snd-rtctimer) appears to hang
some kernels solid when loaded or used. I don't have
much information about that, but I can probably find
out some more.
- ALSA sequencer can sync to a soundcard clock,
but this induces jitter when used with JACK and has
caused confusion for users who find themselves
inadvertently sync'd to an unused soundcard (the
classic "first note plays, then nothing" symptom).
The biggest advantage of course is not having to run
an RT MIDI timing thread. My impression is that this
aspect of MusE (which does that, I think) causes
as many configuration problems for its users as using
ALSA sequencer queue timers does for Rosegarden's.
Any more thoughts on this?
its right that MusE uses a RT midi thread to schedule midi
events. ALSA is used only to deliver (route) midi events.
I think this is the easiest possible solution and gives the app
the best control over timing.
Using the ALSA seq api means that ALSA has to operate the RT thread which
only moves the problems to ALSA.
The ALSA seq api is from ancient time were no realtime threads were
available in linux. Only a kernel driver could provide usable
midi timing. But with the introduction of RT threads the
ALSA seq api is obsolete IMHO.
Midi is synced to audio in MusE by using JACK frame timing to
schedule midi events which is also easy and straightforward.
There is nothing for a user to configure except he changes the
priority of the JACK RT thread.
The priority of the MusE midi RT thread has to be at least one above the
JACK RT priority. The point is that this allows the midi thread
to interrupt the JACK audio process thread which is necessary
to provide acceptable midi timing.
Last note about RT-linux kernels: its not _that_ important. Its
only a micro optimization. A normal recent kernel works pretty well.
If your normal kernel does not operate with sufficient low latencies,
the RT-kernel will most likely also not work.
/Werner