Re: [Rosegarden-user] Rosegarden laggggggiinnnngggg with jackd -P 80

[Ken R. <ke...@re...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 18, 2007 at 08:49:08PM +0000, Chris Cannam wrote:
> On Wednesday 17 Jan 2007 06:47, Ken Restivo wrote:
> > With jackd started with -P 80, on a freebob setup (no ALSA),
> > rosegarden introduces noticeable latency when placed in the MIDI
> > signal path between a controller and fluidsynth. Disconnecting the
> > controller from rosegarden and patching it directly into the
> > softsynth is much faster. With -P 60, no problem, rosegarden doesn't
> > introduce any delay that I can notice.
> >
> > Why would this be? Could jackd with -P 80 be hogging the CPU and not
> > giving it to rosegarden to process incoming ALSA MIDI interrupts?
> 
> Interesting.  You don't say anything about processor load, so I assume 
> this happens even if the CPU time being spent in JACK clients (i.e. 
> approximately the figure shown in the qjackctl window) is low?
> 
> Rosegarden doesn't use real-time scheduling for its MIDI thread, so it's 
> entirely possible for it to be starved by any RT scheduled threads such 
> as the JACK ones.
> 
> This shouldn't make any difference to the recorded timing of incoming 
> MIDI events, which are scheduled and timestamped in the ALSA sequencer 
> driver in the kernel.  If you have a "true" RT kernel, this driver will 
> effectively operate at the priority of your ksoftirqd thread.
> 
> The lack of RT priority in Rosegarden's MIDI thread could certainly 
> cause lag in "MIDI Thru" situations like the one you have, because the 
> events have to go through a non-RT thread between coming in to 
> Rosegarden and going out again.  But (a) this would happen regardless 
> of the priority you set for the JACK thread (because any priority of RT 
> thread will preempt a non-RT thread) and (b) it should only happen when 
> the CPU load is relatively high -- my view, which may be misguided, is 
> that it's better to lag in MIDI monitoring when the system is under 
> load than to drop out from or lose track of audio or MIDI recording or 
> playback.
> 
> The fact that your problem only happens with a high priority JACK thread 
> kind of suggests that what it's starving is the kernel thread used by 
> the ALSA sequencer, not one of Rosegarden's own threads.  That doesn't 
> seem to me to explain why it should cause lags even under no load, if 
> that is the case; also, it would surely affect MIDI record and playback 
> as well as thru.  Still, try upping the priority of the ksoftirqd 
> thread, if you have one.
> 
> See also this page:
> 
>   http://tapas.affenbande.org/wordpress/?page_id=40
> 
> 

Thank you, that link was very helpful! Lays out exactly how to set up RT priorities.

However, it made things worse.

By reading that document, and experimenting a bit, it appears to me that Rosegarden's "auto" mode is probably choosing the system clock instead of the RTC, and that is probably what is getting starved (i.e. the softirq daemon).

Also from reading that document, it was clear that the softirq/system clock is the wrong one to use. So instead I tried to set Rosegarden to use RTC instead.

Would you like to guess what happened next? I certainly didn't expect it.

.... wait for it  ...

All the notes sustain endlessly! That's right! And that's not all. Setting Rosegarden to use RTC causes two problems:

	1) All notes sustain endlessly. Playing with the sustain pedal has no effect. I checked using aseqdump, and determined that my keyboard controller is definitely sending note off messages. And also sustain pedal on/off's were going through according to aseqdump. I recorded some playing and looked at the events that Rosegarden captured: indeed it was getting all the note on's and note off's and sustain pedal on/off's. Patching directly from the keyboard to the fluidsynth instance showed no problem at all: it is only broken when MIDI THRU'ing with Rosegarden.

	2) No MIDI through while recording! And no MIDI playing either. The recording occurs, and notes are definitely getting captured-- indluding note on and note off and sustain controller on/off--, but they are not getting passed through to the fluidsynth while the JACk transport is running. At all. I didn't check to see if the problem persisted with a different transport method. But when the transport is stopped, the notes are getting passed through (even though they sustain endlessly).

I have to admit, after doing this, I just threw up my hands, actually screamed "WTF!!" out loud, shut off the computer, and went out to play acoustic guitar by the beach instead.

That was a lot more fun.

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFsYG6e8HF+6xeOIcRAgR0AKDe1k98lmVTV8oiZQSjPTYC868+bQCeImEB
ajKXpydux09m6gCanGZpDsg=
=w3ln
-----END PGP SIGNATURE-----