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