[PlanetCCRMA] is this issue w/ CCRMA jack2 or 'drumstick-sysinfo'

[Niels Mayer]

FYI, on LAU in the thread that lead-up to my trying out 'drumstick'
and HRTimer....  I had questions about HRtimer, Paul Davis provides
answers:

http://linuxaudio.org/mailarchive/lau/2010/5/31/169513

On Mon, May 31, 2010 at 6:19 AM, Paul Davis <paul at linuxaudiosystems.com> wrote:
> On Sun, May 30, 2010 at 4:39 PM, Niels Mayer <nielsmayer at gmail.com> wrote:
>>
>> On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul at 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-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.
>
> --p
>