<br><br><div class="gmail_quote">On Sun, May 30, 2010 at 4:39 PM, Niels Mayer <span dir="ltr"><<a href="mailto:nielsmayer@gmail.com">nielsmayer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="im">
On Fri, May 28, 2010 at 12:11 PM, Paul Davis <<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>> wrote:<br>
>> Does setting "--clocksource" only affect MIDI, or also Audio?<br>
>> ( <a href="http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p28587664.html" target="_blank">http://old.nabble.com/Re:-Quality-of-sound-on-RHEL-6.0-beta-and-Fedora-13-p28587664.html</a> )<br>
><br>
> neither.<br>
<br>
</div>Then what is the purpose of the --clocksource flag, and what are the<br>
advantages/disadvantages of the different settings:<br>
"c(ycle) | h(pet) | s(ystem)"??<br></blockquote><div><br>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").<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In a different thread you mention, regarding jackd's use of snd-seq:<br>
> 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".<br>
<br>
Would using snd-hrtimer with snd-seq change this assessment? </blockquote><div><br>No, they are just badly designed and implemented from this perspective. They both have substantial jitter built into their design. <br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I haven't<br>
done any precise measurements myself, but I didn't hear anything sound<br>
terribly "off" w/r/t my usage of ALSA midi through qjackctl/jackd (<br>
"/usr/bin/jackd -dalsa -dhw:M66 -r44100 -p256 -n2 -Xseq -zs -H -M").<br>
Certainly not "unusable" just using MIDI alone.<br></blockquote><div><br>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.<br>
<br>--p<br><br></div></div>