|
From: Clifford D. <bea...@gm...> - 2012-11-28 00:15:20
|
> 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 |