[LAU] qtractor MIDI queue timer (was: qtractor crashes)

[Philipp Überbacher]

Excerpts from Rui Nuno Capela's message of 2010-06-06 13:37:33 +0200:
> On 06/06/2010 07:35 AM, Niels Mayer wrote:
> > What happens if I use "HR timer" instead of "(default)" or a specific
> > PCM slave, when recording/playing back audio clips ?
> > Does "PCM playback (slave)" mean the audio sample-clock is sync'd to
> > the midi clock, or vice-versa? And if snd-hrtimer is available,
> > wouldn't both audio and midi be using the same clock? (per Grant's
> > comment ''CONFIG_SND_HRTIMER says: "ALSA uses the hrtimer as a precise
> > timing source. The ALSA sequencer code also can use this timing
> > source."'' )
> > 
> > W/r/t qtractor, does (default) "do the right thing" or should I be
> > choosing a specific option based on use?
> > 
> 
> afaict, this midi queue timer resolution deals _only_ with the specific
> timer assigned to the alsa sequenecer (midi) queue; it has nothing to do
> nor messes with the timing source chosen in jackd -c.
> 
> rationale goes like that you should use the highest resolution timer
> available (snd-hrtimer). anyhow, as far as qtractor or rosegarden goes,
> timer selection should be carried out fundamentally in an attempt to
> minimize jitter between the audio (jack) and midi (alsa-seq) streams,
> allowing a much better and precise drift compensation between the two
> clocks (audio's and midi's).
> 
> bottom line goes about to use the highest resolution timer your system
> allows you to. it is not that clear to me that for best results both
> jack and alsa-seq clocks should be of the same source. jack/audio time
> source should be a most regular one whereas the alsa-seq/midi timer
> should be of the highest resolution (granularity) possible.
> 
> nb. if using the vanilla stock kernel, the default system timer is a
> extremely poor resolution one (250hz) so that using a pcm slave timer is
> the next best choice, if hrtimer is not found available, that is. the
> "(default)" system timer has been doing the right thing here for ages,
> but i do always care to have the system timer resolution set on 1000hz
> (custom kernel).

At least the default depends, it's 300 here, but I guess that doesn't
make a hell of a difference :)

> however, i remember some mixed reports that the hrtimer is a scarce
> system resource, prone to exhausting and freezing lock-ups. maybe that's
> just a recurring myth by now, given the latest and greatest kernels.
> 
> usually ymmv :)
> 
> > I guess I'll find out...
> 
> yep. try && tell

Now that I have a hrtimer capable machine I gave it a shot with jack,
the results were weird to say the least.

I got jackd -c h to work without complains, but then nothing else could
access the hrtimer, neither a2jmidid nor synths that try to do the same.
The really weird part however started when I connected a jack midi
sequencer to my hardware piano. Once the piano was connected to the
sequencers in and the sequencers out back to the piano I suddenly got
tons of xruns. I didn't experiment further to narrow down in which cases
it happens and in which it doesn't, but I'm sure it's in some way
related to jack running with jackd -c h.
I should probably mention that I did this test with tschack-git.
Just thought I drop this little piece of experience here.
-- 
Regards,
Philipp

--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan