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

Florian Schmidt mista.tapas at gmx.net
Fri Dec 30 17:06:32 UTC 2005


On Fri, 30 Dec 2005 17:37:13 +0100
Werner Schweer <ws at seh.de> wrote:


> 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. 

This is my understanding also. 

> 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.

I wouldn't say obsolete, but IMHO RT thread based midi dispatching is
more easy to get right.

> 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.

Yep. I agree.

Is this "one above the JACK RT priority" automated in muse? Your first
sentence seems to imply otherwise. It's probably a reasonable approach
to do it this way. Although manual user overide would be nice, too.

> 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.

I do not agree. While this is true for an otherwise unloaded system, it
is rather easy (on a vanilla kernel) to produce xruns by putting other
load on the system.

The IRQ priorization provided by -rt kernels is extremely useful to
avoid these. It is _vital_ to run jackd with a priority higher than
those IRQ handlers not doing audio/midi stuff (network, disk, etc). The
soundcard IRQ handler must run with a high prio for this to work, too.
I'm not all too sure about whether it matters which of the two (jack or
soundcard irq) is higher though, as long as both are higher than other
irq handlers.

It is very useful to be able to do other stuff while audio/midi is
working uninterrupted. I got used to be able to compile a kernel
alongside running jackd with a periodsize of 32 or 16 frames :) which
means, i can play o.e. guitar while waiting for the damn compile to
finish.

Flo

P.S.: softsynths need to have their midi thread higher prio than jackd,
too, for the flawless midi timing to work. So i suppose it's time for
some bug reports to softsynth authors :)

-- 
Palimm Palimm!
http://tapas.affenbande.org



More information about the Linux-audio-dev mailing list