6 Jun
2010
6 Jun
'10
1:34 p.m.
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).
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
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org