17 Mar
2010
17 Mar
'10
5:57 a.m.
On 17 March 2010 13:43, Ken Restivo <ken(a)restivo.org> wrote:
On Tue, Mar 16, 2010 at 11:25:25PM +0100,
fons(a)kokkinizita.net wrote:
Holy crap thanks for bringing this up. I had always wanted to know
this so I could make my Zoom be helpful during travel.
--
GPG/PGP ID: B42DDCAD
On Tue, Mar 16, 2010 at 02:31:29PM -0700, Ken
Restivo wrote:
Genius. That's exactly the kind of solution I was hoping for. Thank you very much!
I'll try that.
Any ideas how to measure latency on this thing a
"manual" way, not using Fons's tool, and given that there's no way to
turn off monitoring, so I can't just pipe the line out into the line in as a loop
without getting some awful digital feedback.
If the monitoring is stereo (L->L, R->R), you could try to
connect line-out-L to line-in-R, then use out-L and in-R
with jack_delay.
If the latency is really 'seconds' it
will be above
jack_delay's ambiguitiy interval which is 2^16 samples.
In that case you'd have to add some integer times 2^16
samples to the measurement to get the real delay.
My back-of-the-envelope calculation, done by manually moving a percussion track in Ardour
until it sync'ed up with the drumkit, and then noting the difference in the region
start times, is that the latency through the Zoom is either exactly two seconds, or
Ardour's region start time resolution doesn't go to fractions of seconds.
I'll try that trick with jack_delay and see how far I get with that.