[ardour-dev] testing plugin latency compensation and alignment

[Paul Davis]

> Record Click to track with input 'ardour click out 1'
> Recorded Click is early. First beat's attack is missing. Second is at

yes, this caused me significant headaches when i was working on the
code. the problem, if it really is a problem, is that ardour does a
declick fade-in and fade-out at transport start/stop which affects stuff
like this. 

> 20002 frames rather than 22050 where it should be.

you had the wrong alignment choice for recording the click. thats OK for
the purposes of this test.

> Record Click to track with loopback input 'alsa pcm capture:1'
> Recorded Click is late. First beat is at 190 frames rather than 0.

190 frames sounds about right for the D/A and A/D converters in your
system, assuming its not an all-digital unit. let me know.

> Test 2: Recording the click. 
> Ardour settings: align recorded material with exact time recorded.
> 
> Record Click to track with input 'ardour click out 1'
> Recorded click is exactly in time.

as expected.

> Record Click to track with loopback input 'alsa pcm capture:1'
> Recorded Click is late. First beat is at 2238 frames rather than 0.

yes, it should be late, 1 period + (in your case) about 190 frames.
perfect.

> 
> Test 3: Re-recording the recorded exactly in time click track to a new
> track. 
> Ardour settings: Align recorded material with existing material.
> 
> Record Click to track with loopback input 'alsa pcm capture:1'
> Recorded Click is late. First beat faded in (see misc notes).
> Second beat is at 22240 frames rather than 22050.

again, about 190 frames - D/A + A/D delays, i hope.

> Test 4: Re-recording the recorded exactly in time click track. An
> artificial latency plugin set to 400ms is inserted on an unused audio
> track.
> Ardour settings: Align recorded material with existing material.
> 
> Record to track with loopback input 'alsa pcm capture:1'
> Recorded Click is late. First beat is at 2238 frames rather than zero.

as above, perfect given the assumption about converter delays.

> Misc stuff noted:
> If you play a recorded click track starting at 0, the first beat has a
> slight fade in even if fades are disabled on that region. Drag it about

see comments above.

> 1000 frames to the right and the fade is no longer there. Alignment
> settings have no effect on this. If the artificial latency plugin is on
> an insert, this problem no longer happens. Preroll too short?

it vanishes when you have a latent plugin because the delayed track
doesn't start rolling till after the transport startup declick is over.

> When using the artificial latency plugin, the transport continues
> rolling after you press stop. The audio played back while it is still
> rolling is oddly quiet and distorted with little pre echos in it.

it wouldn't be so odd with a real situation. i ran into the same kind of
oddness, and spent a while figuring out what was going on. we keep
rolling because we're waiting for tracks that are recording to collect
all the data that may still be coming in from the outside world.

> In conclusion:
> 
> First, there is always a 190 frame offset on loopback with this card
> when using 'Align with existing material'.
> This offset did not change when jackd 'frames per period' was altered
> from 2048 to 256. 190 frames seems a little too big for converter delay.

85 frames is about 1.9msec at your SR. a little large, i agree, but
inline with numbers i've seen quoted for a number of converters.

> Second, when the artificial latency plugin is used, the latency
> compensation seems to compensate for plugin latency, but the jack/sound
> card latency stops being compensated for.

not sure what you mean by this. i will have to digest your extra test
for a bit longer.

thanks!

--p