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@xxxxxxxxx _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
