16 Mar
2010
16 Mar
'10
6:33 p.m.
I have been boxed into a little corner here since the band that shares our practice room
has run off with all of our mics and cables, so I can't use my M-Audio FastTrack for
recording, and instead have been reduced to using a Zoom H2 as a mic.
It sounds good, but the latency is horrendous, like seconds, even though it supposedly has
the same latency settings 128/n3 that I use on the M-Audio.
I've been tracking with it and it's a huge PITA to always have to be shifting
tracks over in Ardour after they're recorded.
What's worse, there's no way to turn off hardware monitoring on it, so I can't
use Fons' excellent jack_delay tool to measure the latency.
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.
Finally, once I theoretically do obtain that information, is there any way in Ardour to
shift a region over by an exact number of milliseconds or samples? i.e. instead of
dragging it, to set it's start position by typing in a number?
Thanks.
-ken
16 Mar
16 Mar
6:47 p.m.
On Tue, 2010-03-16 at 14:31 -0700, Ken Restivo wrote:
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.
Measure the period of the feedback?
Play back a single click on a track, use the Zoom to record it from the
speakers to another track and measure the delay?
Gordon MM0YEQ
7:12 p.m.
On Tue, Mar 16, 2010 at 09:52:50PM +0000, Gordon JC Pearce wrote:
On Tue, 2010-03-16 at 14:31 -0700, Ken Restivo wrote:
Should work. Or rerecord it with line-out connected to
line-in via an some attenuator to keep the loop gain just
below one. If you can set up such a connection it could
be measured with sample accuracy using aliki.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
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.
Measure the period of the feedback?
Play back a single click on a track, use the Zoom to record it from the
speakers to another track and measure the delay?
7:29 p.m.
On Tue, Mar 16, 2010 at 02:31:29PM -0700, Ken Restivo wrote:
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.
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
17 Mar
17 Mar
2:44 a.m.
On Tue, Mar 16, 2010 at 11:25:25PM +0100, fons(a)kokkinizita.net wrote:
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.
Thanks again.
-ken
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. 
18 Mar
18 Mar
6:02 a.m.
On 03/17/2010 06:43 AM, Ken Restivo wrote:
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'm pretty sure that ardour's region start time is sample-accurate.
1:13 p.m.
2010/3/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 03/17/2010 06:43 AM, Ken Restivo wrote:
indeed, it is. it can be displayed in a variety of formats: timecode,
min:sec, BBT, sampletime. right click on any time display in ardour to
change the display mode.
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'm pretty sure that ardour's region start time is sample-accurate.
4:27 p.m.
On Thu, Mar 18, 2010 at 06:51:32AM -0400, Paul Davis wrote:
2010/3/18 J?rn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
Thanks!
That seems it'll be the easiest solution so far. Create a 1-sample impulse and stick
it on an Ardour track. Wire the L output channel of the Zoom to the R input channel. Arm a
track to record from the Zoom, then play the impulse. Then I just have to measure the
distance between them in Ardour using the sample display mode.
-ken
On 03/17/2010 06:43 AM, Ken Restivo wrote:
indeed, it is. it can be displayed in a variety of formats: timecode,
min:sec, BBT, sampletime. right click on any time display in ardour to
change the display mode. 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'm pretty sure that ardour's region start time is sample-accurate.
4:59 p.m.
On Thu, Mar 18, 2010 at 3:25 PM, Ken Restivo <ken(a)restivo.org> wrote:
That seems it'll be the easiest solution so far.
Create a 1-sample impulse and stick it on an Ardour track. Wire the L output channel of
the Zoom to the R input channel. Arm a track to record from the Zoom, then play the
impulse. Then I just have to measure the distance between them in Ardour using the sample
display mode.
easier: create a port insert for a track. bring up the port insert's
GUI. connect to the Zoom. click "measure latency". done. same code as
jdelay, packaged.
5:32 p.m.
On Thu, Mar 18, 2010 at 03:59:04PM -0400, Paul Davis wrote:
easier: create a port insert for a track. bring up the
port insert's
GUI. connect to the Zoom. click "measure latency". done. same code as
jdelay, packaged.
Interesting...
This adds one period to the value to be measured
in this case.
Note that jdelay expects a 'linear phase' path,
i.e. delay should not depend on frequency.
Any filtering or EQ will make it fail. It would
be possible to reduce the sensitivity to phase
errors changing the algorithm paramaters.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
6:19 p.m.
On Thu, Mar 18, 2010 at 03:59:04PM -0400, Paul Davis wrote:
On Thu, Mar 18, 2010 at 3:25 PM, Ken Restivo
<ken(a)restivo.org> wrote:
Thanks. I did it the long way, and the magic answer is...
8267 samples of latency at 44.1Khz on the Zoom.
Ardour's timecode display shows 8267 samples as 5 seconds. But at 44100 samples per
second, shouldn't 5 seconds be 220500 samples? Likewise, wouldn't 8267 samples be
more like 0.188 seconds of delay?
-ken
That seems it'll be the easiest solution so
far. Create a 1-sample impulse and stick it on an Ardour track. Wire the L output channel
of the Zoom to the R input channel. Arm a track to record from the Zoom, then play the
impulse. Then I just have to measure the distance between them in Ardour using the sample
display mode.
easier: create a port insert for a track. bring up the port insert's
GUI. connect to the Zoom. click "measure latency". done. same code as
jdelay, packaged. 
6:29 p.m.
On 18 March 2010 at 14:17, Ken Restivo <ken(a)restivo.org> wrote:
On Thu, Mar 18, 2010 at 03:59:04PM -0400, Paul Davis
wrote:
How did you create your 1 sample impulse? Having that could be
very useful for a lot of things.
On Thu, Mar 18, 2010 at 3:25 PM, Ken Restivo
<ken(a)restivo.org> wrote:
Thanks. I did it the long way, and the magic answer is... That seems it'll be the easiest solution so
far. Create a
1-sample impulse and stick it on an Ardour track. Wire the
L output channel of the Zoom to the R input channel. Arm a
track to record from the Zoom, then play the impulse. Then
I just have to measure the distance between them in Ardour
using the sample display mode.
easier: create a port insert for a track. bring up the port
insert's GUI. connect to the Zoom. click "measure latency".
done. same code as jdelay, packaged. 8267 samples of latency at 44.1Khz on the Zoom.
Zoom H2? H4?
Thanks.....
--
Kevin
8:52 p.m.
On Thu, Mar 18, 2010 at 11:12:34PM +0100, fons(a)kokkinizita.net wrote:
On Thu, Mar 18, 2010 at 02:17:05PM -0700, Ken Restivo
wrote:
Thanks. That was the problem. 0.188 seconds, 8267 samples.
I thought the default view "timecode" in Ardour was in units of minutes:seconds,
but it wasn't, it was some other weird unit ("frames") that I don't
understand.
So, my 2-seconds estimate was totally wrong, I had been moving the tracks over by entire
beats to try to get them to sync up.
-ken
Ardour's timecode display shows 8267 samples
as 5 seconds.
It's more like 5 *frames*.
Switch the display to minutes:seconds instead of timecode.
10:37 p.m.
On Thu, Mar 18, 2010 at 7:50 PM, Ken Restivo <ken(a)restivo.org> wrote:
I thought the default view "timecode" in
Ardour was in units of minutes:seconds, but it wasn't, it was some other weird unit
("frames") that I don't understand.
timecode has a very specific meaning. its a way to refer to video
time, which is measured in hours:minutes:seconds:video-frames (there
are typically 24-30 video frames per second, so the final field is
displaying approximately 1/30ths of a second).
its a very common way to deal with time in many situations where DAWs
are used. ardour3 saves all your chosen clock modes so that you never
have to see this again if you don't want to :)
--p
16 Mar
16 Mar
9:38 p.m.
________________________________
From: Ken Restivo ken(a)restivo.org
What version of the Operating System are you using?
I'm running 1.80 In the scroll-down menu listing, there is an entry for Monitor.
I've set it to off. Perhaps this will help.
Here's a link to the software update if you're running an earlier version. Be
careful to follow *all* the directions exactly as given.
http://www.zoom.co.jp/english/download/software/h2.php
Also, have you tried using it as a USB microphone and done the recording outside of the
Zoom H2? That may help.
Good Luck,
Stephen.
It sounds good, but the latency is horrendous, like seconds, even though it supposedly has
the same latency settings 128/n3 that I use on the M-Audio.
I've been tracking with it and it's a huge PITA to always have to be shifting
tracks over in Ardour after they're recorded.
What's worse, there's no way to turn off hardware monitoring on it, so I can't
use Fons' excellent jack_delay tool to measure the latency.
=====================
5214
days inactive
5216
days old
linux-audio-user@lists.linuxaudio.org
16 comments
8 participants
participants (8)
-
fons＠kokkinizita.net -
Gordon JC Pearce -
Jörn Nettingsmeier -
Ken Restivo -
Kevin Cosgrove -
Paul Davis -
Ray Rashif -
Stephen Stubbs