On Mon, May 31, 2010 at 09:19:06AM -0400, Paul Davis wrote: > On Sun, May 30, 2010 at 4:39 PM, Niels Mayer <nielsmayer@xxxxxxxxx> wrote: > > > > > On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> > > wrote: > > >> Does setting "--clocksource" only affect MIDI, or also Audio? > > >> ( > > http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p28587664.html) > > > > > > neither. > > > > Then what is the purpose of the --clocksource flag, and what are the > > advantages/disadvantages of the different settings: > > "c(ycle) | h(pet) | s(ystem)"?? > > > > JACK makes quite a few calls to get a wallclock time value. Its original > implementation always used the cycle counter to minimize the overhead of > getting this value, since gettimeofday() is technically a system call and > its better to avoid such things in most of the places that JACK needs to > know the wallclock time. However, as has been mentioned, it turns out that > using the cycle counter on many machines is deeply problematic, and so by > default JACK uses gettimeofday(). The HR timer offers similar properties as > the cycle counter in the sense that no system call is required to read it. > The choice between these 3 options has nothing really to do with "timing" at > all (although on a machine with a weak cycle counter implementation, using > the cycle counter will cause "timing problems"). > > > > In a different thread you mention, regarding jackd's use of snd-seq: > > > the timing behaviour of the two -X options (seq and raw) are not very > > good. some might be sufficiently uncharitable as to call them unusable". > > > > Would using snd-hrtimer with snd-seq change this assessment? > > > No, they are just badly designed and implemented from this perspective. They > both have substantial jitter built into their design. > > I haven't > > done any precise measurements myself, but I didn't hear anything sound > > terribly "off" w/r/t my usage of ALSA midi through qjackctl/jackd ( > > "/usr/bin/jackd -dalsa -dhw:M66 -r44100 -p256 -n2 -Xseq -zs -H -M"). > > Certainly not "unusable" just using MIDI alone. > > > > The issue is not using ALSA MIDI. Its routing from JACK to ALSA MIDI. If > this is not designed and implemented correctly, it can end up with large > amounts of jitter (variable delays in how long it takes to actually deliver > MIDI data to its destination). a2jmidid (at least relatively recent > versions) is correctly designed and implemented in this respect. > Really? It's probably been a couple years since I used a2jmidid, but I recall it having horrible jitter and latency (when using AZR3, which I used to use a lot) compared to the -Xseq option in jackd. -ken _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
