Re: [FFADO-user] MOTU Ultralite, Jack, and Latency

[Clifford D. <bea...@gm...>]

> Which version of jackd are you using?  If jack1 then AFAIK "-S" has no
> effect.  With jack2 (aka jackmp) it activates synchronous mode.  Is there
> any particular reason you're wanting that?  While this mode has some
> advantages in certain circumstances, it does add an additional buffer to one
> of the directions (sorry, I can't recall whether it's outgoing or incoming).

I believe my version of  jackdmp is 1.9.8. I found a blog that told me
that synchronized jack is best to use hence the -S....It's not
something I would have chosen on my own.
>
> You mentioned that you'd experimented with frames/periord (jack's "-p"
> option).  Have you also experimented with the "-n" parameter?  Also, what
> sample rate are you using?  Are you able to determine what jackd command
> line options are actually in use?  This may help us to identify possible
> tweaks.  The total latency depends on the sample rate as well as the
> settings of "-p" (frames per period) and "-n" (number of buffers).  It's all
> inter-related.

I'm using qjackctl...so I'm not sure which parameters line up to which
feature. I do have it set to run 2 periods/buffer, and 44100 sample
rate.
>
> I don't think I've ever taken my MOTU down below 128 frames/period (although
> having written that I have a vague recollection that I might have had it
> going with "-p 64" at some point).
>
> It may also be worth experimenting with Fons's jack_delay application.  With
> this you physically connect a device output to an input with a cable.  You
> then run jack_delay, telling it which ports you've used.  By utilising a
> series of sine waves of different frequencies this program will then report
> the total real round-trip latency to sub-sample accuracy.  It's a cool
> trick.  And because this figure takes the device's internal delays into
> account (something which jackd can't know anything about) it more accurately
> depicts the real latency (the latency reported by jack only accounts for the
> jackd buffers).  True, it's round-trip, but to a first order approximation
> in most cases playback and record latency is the same[1], so you can
> estimate the one-way latency just by dividing by two.
>

Sounds great. This is what I'm really interested in, so I'll look into this.

Thanks!


Clifford Dunn
Flutist/Composer
http://www.clifforddunnmusic.com
http://www.myspace.com/clifforddunn
http://www.youtube.com/user/beatleboy07