6 Jun
2010
6 Jun
'10
2:10 p.m.
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:
At least the default depends, it's 300 here, but I guess that doesn't
make a hell of a difference :)
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). 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 :)
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
I guess I'll find out...
yep. try && tell