On Sun, May 30, 2010 at 4:39 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul(a)linuxaudiosystems.com>
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-p…)
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.
--p