HW insert Delay Compensation strange behavior on Pro Tools Ultimate

[ejsongs]

I've said this before...how about upgrading to hdx...then there is no need to ping anything. What you are asking for is inferior to what we have had for years....like over a decade...maybe 15 years...just sayin...

[BScout]

Originally Posted by ejsongs

I've said this before...how about upgrading to hdx...then there is no need to ping anything. What you are asking for is inferior to what we have had for years....like over a decade...maybe 15 years...just sayin...

This is not true. Hardware insert delay still exists on HDX

[ejsongs]

Originally Posted by BScout

This is not true. Hardware insert delay still exists on HDX

I’ve been using hardware inserts for ages with no issues. I can track this way if I choose and insert dsp and/or native on the same track for the most part. I have never had to think about pingin because pt compensates for it when using their interfaces. It just works…literally plug and play.

Is this not your experience? This is not the case obviously with your mtrx interfaces which isn’t one of the main reasons I have not gone in that direction.

Ej

[Darryl Ramm]

Pro Tools (at least 2022.4 Studio) also compensates for insert delay including conversion time when third party interfaces correctly advertise their latency data.

I've been doing some systematic measurement of insert delay behavior with Pro Tools Studio 2022.4 with three RME interfaces I have (Fireface UFX+, MadiFace, Digiface) . I am very impressed by the insert behavior automatic selection of insert latencies based on what the RME driver is advertising. Like perfect sample accurate insert adjustment at multiple different clock rates, IO buffer sizes etc. The hardware insert DLY shown in the Pro Tools track delay compensation is calculated from the driver latency parameters. So if a driver is advertising bad parameters this could create the need for a negative manual compensation.

Impressive stuff, and unlike the documentation implies does seem to correct for conversion time (but again relies on the driver correctly advertising the correct latencies). And checking this by hand in Pro Tools, Logic Pro (using ping), RTL Utility and Apple's AU Lab stuff everything agrees to within a sample.

So one thing to suspect with third party/non-DigiLink interfaces if your insert behavior is a mess, negative offsets etc. is the driver is just advertising garbage. RTL Utility (https://oblique-audio.com/rtl-utility.php) or AU Lab (https://www.apple.com/apple-music/apple-digital-masters - see Preferences>Devices>Expert Settings) will tell you exactly what the driver is saying it's RTL latency is, and that RTL latency should be the same as shown in the Pro Tools track DLY compensation for the hardware insert. So for folks seeing negative numbers lets start seeing what RTL Utility or AU Lab reports for your interface. Start comparing things without ignore errors checked and with no plugins in the session , and low latency monitoring not enabled. (and this will only work correctly for the primary IO ports on an interface since the interface can only advertise one latency (e.g. if your interface has analog I/O and a bunch of ADAT expansion, then the driver will typically advertise the latency for the analog ports (it has no idea what the latency is of anything hanging off ADAT)).

And then there is behavior I've seen only a few times while doing hundreds of tests when opening a new sessions in Pro Tools and it does gets the latency calculations wrong. Sometimes the calculated DLY it too long (producing the need for negative manual adjustments I've seen things like being too fast by several tens of samples), sometimes too short. It seems to happen when switching Pro Tools between sessions with different sample rates. it does not happen enough to get more of a handle on it, but exciting Pro Tools, disconnecting the interface cable and reconnecting it and restating Pro Tools has always fixes this so far. Who knows if this is related to anything others have seen with negative latencies, or is just something coincidental, something specific to RME etc.

I'll have a spreadsheet with notes ready to share soon. Trying to make it understandable.

[digiot]

Originally Posted by Darryl Ramm

Pro Tools (at least 2022.4 Studio) also compensates for insert delay including conversion time when third party interfaces correctly advertise their latency data.

I've been doing some systematic measurement of insert delay behavior with Pro Tools Studio 2022.4 with three RME interfaces I have (Fireface UFX+, MadiFace, Digiface) . I am very impressed by the insert behavior automatic selection of insert latencies based on what the RME driver is advertising. Like perfect sample accurate insert adjustment at multiple different clock rates, IO buffer sizes etc. The hardware insert DLY shown in the Pro Tools track delay compensation is calculated from the driver latency parameters. So if a driver is advertising bad parameters this could create the need for a negative manual compensation.

Impressive stuff, and unlike the documentation implies does seem to correct for conversion time (but again relies on the driver correctly advertising the correct latencies). And checking this by hand in Pro Tools, Logic Pro (using ping), RTL Utility and Apple's AU Lab stuff everything agrees to within a sample.

So one thing to suspect with third party/non-DigiLink interfaces if your insert behavior is a mess, negative offsets etc. is the driver is just advertising garbage. RTL Utility (https://oblique-audio.com/rtl-utility.php) or AU Lab (https://www.apple.com/apple-music/apple-digital-masters - see Preferences>Devices>Expert Settings) will tell you exactly what the driver is saying it's RTL latency is, and that RTL latency should be the same as shown in the Pro Tools track DLY compensation for the hardware insert. So for folks seeing negative numbers lets start seeing what RTL Utility or AU Lab reports for your interface. Start comparing things without ignore errors checked and with no plugins in the session , and low latency monitoring not enabled. (and this will only work correctly for the primary IO ports on an interface since the interface can only advertise one latency (e.g. if your interface has analog I/O and a bunch of ADAT expansion, then the driver will typically advertise the latency for the analog ports (it has no idea what the latency is of anything hanging off ADAT)).

And then there is behavior I've seen only a few times while doing hundreds of tests when opening a new sessions in Pro Tools and it does gets the latency calculations wrong. Sometimes the calculated DLY it too long (producing the need for negative manual adjustments I've seen things like being too fast by several tens of samples), sometimes too short. It seems to happen when switching Pro Tools between sessions with different sample rates. it does not happen enough to get more of a handle on it, but exciting Pro Tools, disconnecting the interface cable and reconnecting it and restating Pro Tools has always fixes this so far. Who knows if this is related to anything others have seen with negative latencies, or is just something coincidental, something specific to RME etc.

I'll have a spreadsheet with notes ready to share soon. Trying to make it understandable.

Looking forward to see the spread sheet! Thanks in advance for putting in all that research.

[BScout]

Originally Posted by ejsongs

I’ve been using hardware inserts for ages with no issues. I can track this way if I choose and insert dsp and/or native on the same track for the most part. I have never had to think about pingin because pt compensates for it when using their interfaces. It just works…literally plug and play.

Is this not your experience? This is not the case obviously with your mtrx interfaces which isn’t one of the main reasons I have not gone in that direction.

Ej

The 192 analogue i/o were accurate. The digital i/o on those were not necessarily (we have Quantec, 480L, PCM, and TC Sys6000 wired in.) Can't remember if I ever checked the HD i/o (most of those went away for us in a few years to MADI HD and now MTRX.) I think there's one system that still has 2 HD I/O on it that I can check (but it isn't used for inserts.)
And then, of course, the modular patching of the MTRX units is not always accurate.

When we jump to all the other hardware that can connect to HDX digilink today, its a mixed bag (back in the day, one Apogee firmware was right in its emulation and one wasn't, Lynx was faster than Avid's hardware, etc. Today I've seen Antelope hardware be completely off in its emulation.)

There's enough variety in hardware there for HDX that just saying it fixes this is not true. If someone were to go buy HDX hardware and then get mad it wasn't sample accurate with no effort, I wouldn't blame them if they were hearing blanket statements.

[BScout]

Originally Posted by Darryl Ramm

And then there is behavior I've seen only a few times while doing hundreds of tests when opening a new sessions in Pro Tools and it does gets the latency calculations wrong. Sometimes the calculated DLY it too long (producing the need for negative manual adjustments I've seen things like being too fast by several tens of samples), sometimes too short. It seems to happen when switching Pro Tools between sessions with different sample rates. it does not happen enough to get more of a handle on it, but exciting Pro Tools, disconnecting the interface cable and reconnecting it and restating Pro Tools has always fixes this so far. Who knows if this is related to anything others have seen with negative latencies, or is just something coincidental, something specific to RME etc.

For RME:
Do you have the "short safety offset" checkbox checked in the RME settings during these tests?
When things get off, is the RME being accessed by other software in the background (so is it in use as multi-client -- including, possibly, assigned in Audio MIDI Setup for sounds)?

[ejsongs]

Originally Posted by BScout

The 192 analogue i/o were accurate. The digital i/o on those were not necessarily (we have Quantec, 480L, PCM, and TC Sys6000 wired in.) Can't remember if I ever checked the HD i/o (most of those went away for us in a few years to MADI HD and now MTRX.) I think there's one system that still has 2 HD I/O on it that I can check (but it isn't used for inserts.)
And then, of course, the modular patching of the MTRX units is not always accurate.

When we jump to all the other hardware that can connect to HDX digilink today, its a mixed bag (back in the day, one Apogee firmware was right in its emulation and one wasn't, Lynx was faster than Avid's hardware, etc. Today I've seen Antelope hardware be completely off in its emulation.)

There's enough variety in hardware there for HDX that just saying it fixes this is not true. If someone were to go buy HDX hardware and then get mad it wasn't sample accurate with no effort, I wouldn't blame them if they were hearing blanket statements.

I’m still running:

Avid Omni
Avid 16 I/o
1x192’s

All for that very reason….accuracy.

I’m assuming that with all of your digital verbs and such that you were running them all via aes? Curious if you were getting your word clock via ads or were you using bnc connections with a clock? Most of my connected gear is analog so I haven’t thought about testing latency there as usually when I’m using verbs there is pre delay. Can you elaborate more on your issues with digital gear?

Thanks,

Ej

[BScout]

Originally Posted by ejsongs

I’m assuming that with all of your digital verbs and such that you were running them all via aes? Curious if you were getting your word clock via ads or were you using bnc connections with a clock? Most of my connected gear is analog so I haven’t thought about testing latency there as usually when I’m using verbs there is pre delay. Can you elaborate more on your issues with digital gear?

Thanks,

Ej

We check with loopback first (no gear). Then we check with the gear in but in bypass. Much of these were digital reverbs so it didn't matter much but the System 6000 has a lot more on offer. The issue was always to make sure thing that needed to work in parallel to dry signal always were aligned and when putting things into bypass it didn't change the mix (other than removing whatever was added by that hardware.) And we were able to do it but you have to be familiar with the insert delay page.

We have house wordclock with distributors per studio. But not all gear accepted wordclock. Most gear was AES, some was toslink or spdif (I honestly can't remember it all because we had a lot of purchased gear but also a lot of protoypes, etc that would come in to get endorsements from the studio owner -- so that stuff was varied and would stay for a few months up to a year.) Wordclock wouldn't affect delay comp (if it did, we'd be into pitch-shifting territory

[Darryl Ramm]

Originally Posted by BScout

For RME:
Do you have the "short safety offset" checkbox checked in the RME settings during these tests?
When things get off, is the RME being accessed by other software in the background (so is it in use as multi-client -- including, possibly, assigned in Audio MIDI Setup for sounds)?

Good questions. No I deliberately do not have short safety enabled in the driver, I was going to do a few spot checks on that later. I also never use short safety in normal use. And AU Lab reports both safety latencies and that data is recorded for each test and all those numbers across all tests are consistent except for these odd times I need to restart stuff. None of these devices are ever assigned for macOS sound (I know that as macOS sound is going out my Grace m920).

It is possible I accidentally had Pro Tools and multiple test apps open at once. Tried not to but frankly was getting punch drunk. That is a good suspicion for what might be able to cause this problem. The RME drivers are nicely multiclient but this might be too much to ask for/dependent on the behavior of the other client. I'll get the "good numbers" out first then try to reproduce failures. Now dealing with some stupid problem with MADI routing and Totalmix that is not making sense, time to reset everything...