h/w insert delay compensation not correct

[mennis04]

I followed the instructions for determining the h/w insert delay from pro tools reference guide. Delay compensation on. Create two tracks, a tone on track 1, HW insert on track 1.Bus the output of track 1 to track 2. But when I record a tone to track 2, track 2 is ahead of track 1. Shouldn't it be behind? I'm sure I'm missing something.

[Darryl Ramm]

Hi, welcome to DUC.

Sounds like you have an incorrect value set for the insert delay. Or just try turning delay comp off and see what you get then.

Do all this in a totally empty new session. No plugins nothing else just two mono tracks. And no the track you are playing into from the prerecorded track can't be ahead of the prerecorded track, causality and all that.

You should have already tried trashing prefs, always start troubleshooting with that. See "help us help you" up the top of each web page.

Still stuck, give more info...

Screenshots of your measurement tracks showing the insert and I/O selectors.
Screenshots of the Setup>IO>HW Insert Delay page
Does the outboard box work at all for you?
What latency/difference are you measuring?
What is the hardware delay set to?
What exact interface? brand/model.
What I/O ports are you connecting the outboard box to?
What exact outboard effects box? brand/model.
What do you measure if you use a straight through cable instead of an outboard box?

[Top Jimmy]

If you're using the H/W Insert Delay settings, understand that Pro Tools already automatically compensates for the I/O delay of your interface. IOW, if your interface is set to a buffer of 256, Pro Tools will already account for the 512 samples of round-trip delay (plus the converter delay if your interface reports it). The purpose for the H/W Insert Delay setting is to account for any delay incurred in the outboard gear the signal passes through.

[albee1952]

Knowing exactly what interface and what hardware is in play might help the conversation

[bobbriessinck]

Hey,

adding onto this older thread. I'm having this same issue at the moment. Using an Orion32+ Gen3.

With my Orion32 gen1 I always had to manually add insert delay to line up (analog) outboard stuff. I wanted to check this now with my new(er) Orion and now the signal doing the roundtrip is 1ms (48samples at 48kHz) early compared to what went out. HW Insert delay is completely at 0ms on all 32 insert points, and buffer size at 1024 and there are 0 plugins running in the session, thus no extra latency caused by anything else, just fyi.

I've added a screenshot.

I didn't know PT automatically compensates for interface roundtrip latency. Back when I set up my Orion Gen1 a lot of youtube people were doing it like how I described it just now. Is this a new feature?

[Darryl Ramm]

There are other more detailed threads talking about all this, including some I wrote replies in, but I can't find the best ones now so will repeat myself :-( ...

For H/W inserts Pro Tools only provides this correction when ADC is enabled. In contrast time alignment of inputs is done all the time even when ADC is not enabled.

Make sure you are on the latest compatible interface driver.

Make sure that Pro Tools "ignore errors" is not checked, there is a Pro Tools bug where that can introduce latency errors. Just leave that unchecked, it is a bad idea to start with.

Pro Tools will be using the sets of input and output latency data the interface reports over CoreAudio to do this correction when ADC is enabled.

Are you using Thunderbolt or USB 2 for this? I'd check both, presumably Antelope did a real PCIe/Thunderbolt driver here and it's not just USB running over Thunderbolt. So you should see different RTL latencies reported between these interfaces (see below).

Are you looking at analog or ADAT H/W insert loopbacks?

Even if an interface reports a correct latency data for inputs and outputs, and almost all always will, that latency only applies to typically the analog inputs and outputs. And even if an interface reported different latencies for different type if I/O, which is technically possible to do, DAWs seem to ignore subsequent data and just use the main/first I/O ports latency data, typically that for Analog I/O.

In the case of what you have the ADAT inputs and outputs have lower latency than the analog ones and Pro Tools (and other DAWs) would use the latency data provided for the analog I/O and over-compensate for ADAT H/W inserts and they would be moved back in time/appear to have a total negative latency.

The correction for any of these offsets is best done in the track Delay Compensation "+/-" field. Where you can work in positive or negative samples. And the correction in the Setup>IO>H/W Insert Delay should only used to compensate for any actual delays caused by the external hardware.

The Pro Tools documentation for all this is awful.

You can use the free RTL Utility (https://oblique-audio.com/rtl-utility.php) to independently check what RTL latency the driver is reporting though CoreAudio and measure the actual RTL latencty. Other tools (including one I wrote--see me if you think the interface reports bad data) can provide more granularity on all the latency components the driver actuality reports. While Pro Tools has some known bugs here, and most interfaces provide correct data I suspect that some interfaces do sometimes report incorrect data (it might require say a particular sequence of sample rate changes or a particular sequence of interactions only say Pro Tools does to the interface for it to do this).

There are other bugs in Pro Tools that can cause large, errors with H/W inserts, like 2k or 4k samples... a multiple of the disk playback buffer size. Can be seen with H/W inserts following plugins where LLM is enabled. There are too many stupid latency related bugs in Pro Tools, and a lack of useful features like a built in latency ping that modern DAWs have, but with care you should be able to get H/W inserts to work and be sample accurate after ADC compensation.

[bobbriessinck]

Hey,

thanks for getting back to me!
I'll just answer a few of your comments:

- ADC enabled
- ignore errors unchecked
- USB
- latest driver was causing the Orion to glitch into some driver issues and Antelope recommended me going back to an older driver until there's a new update, but I doubt this could be the issue?
- analog out & in, through a Neutrik Bantam bay, 1 cable straight from out to in

So yes it's either PT messing up (no surprises there) or the Orion reporting a wrong latency to PT to compensate for (if I understand correctly). Best to hit up Antelope maybe?

[Darryl Ramm]

Best first to do exactly what I already suggested and measure the actual RTL latency as well as the driver reported RTL latency. That will not necessarily find every problem… but if they disagree then you know it is the driver. Do this test at the sample rate and buffer size you are using and then multiple other sample rates and buffer sizes to see if anything weird happens.These measurements are super quic/easyk to make.

I would test with Thunderbolt just to see what happens.

Make absolutely certain you are not accidentally using an aggregate device as the playback engine.

You should also do Pro Tools troubleshooting 101… trash prefs, try starting with a completely empty session (not from a template). Reproduce this with a simple as possible session. Test from a newly created macOS admin account. Etc.

It is almost guaranteed a waste of time talking to Avid support about this, there are multiple known latency bugs in Pro Tools and nothing seems to be happening. Antelope does not have a great reputation for technical support either, but maybe worth checking with them to see if they are aware of other users seeing similar issues.

[D-Hydrate]

Originally Posted by Darryl Ramm

You can use the free RTL Utility (https://oblique-audio.com/rtl-utility.php) to independently check what RTL latency the driver is reporting though CoreAudio and measure the actual RTL latencty. Other tools (including one I wrote--see me if you think the interface reports bad data) can provide more granularity on all the latency components the driver actuality reports. While Pro Tools has some known bugs here, and most interfaces provide correct data I suspect that some interfaces do sometimes report incorrect data (it might require say a particular sequence of sample rate changes or a particular sequence of interactions only say Pro Tools does to the interface for it to do this).

Thank you for this. That Oblique Audio RTL Utility helped me get much closer to figuring out the correct number for my system (Focusrite Red4Pre connected via HDX). It was 10ms lower than what I needed, but at least it got me much closer than all my attempts prior to using it.

[Darryl Ramm]

Originally Posted by D-Hydrate

Thank you for this. That Oblique Audio RTL Utility helped me get much closer to figuring out the correct number for my system (Focusrite Red4Pre connected via HDX). It was 10ms lower than what I needed, but at least it got me much closer than all my attempts prior to using it.

You are using this with Pro Tools HDX or another DAW via CoreAudio?

H/W Insert ADC with HDX and HD Native works different than with CoreAudio, which you likely know.

HDX and HD Native just assume the latency of whatever box is being emulated like a HD I/O. But the problem is Focusrite emulates a HD I/O but did not match the latency of a HD I/O. Some other vendors do with their Digilink boxes. I would hope vendors who don't emulate the correct latency would just publish what their RTL latency is/what differences to set in Pro Tools. You can't assume that Pro Tools interface latency with CoreAudio and Pro Tools will be the same... but you can measure the Pro Tools/Digilink latency here by having a separate CoreAudio interface and measuring what it's RTL is and then insert the Digilink interface (with Pro Tools running on it and connecting an input to an output) as if it was an insert box on the other interface and measure the increase in latency.