On Fri, 30 Dec 2005 17:37:13 +0100 Werner Schweer <[EMAIL PROTECTED]> 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
