Re: [LAU] Is ALSA using hrtimer?

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@email-addr-hidden> wrote:
>
> >
> > On Fri, May 28, 2010 at 12:11 PM, Paul Davis <paul@email-addr-hidden>
> > 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Jun 6 00:15:03 2010