30 Dec
2005
30 Dec
'05
12:06 p.m.
On Fri, 30 Dec 2005 17:37:13 +0100
Werner Schweer <ws(a)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