On Sun, May 30, 2010 at 4:39 PM, Niels Mayer <nielsmayer@xxxxxxxxx> wrote:
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").
No, they are just badly designed and implemented from this perspective. They both have substantial jitter built into their design.
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.
--p
On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:Then what is the purpose of the --clocksource flag, and what are the
>> 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.
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.
--p
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
