[linux-audio-dev] Audio/Midi system - RT prios..

[Werner Schweer]

On Friday 30 December 2005 16:17, Chris Cannam wrote:
> 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