HW insert Delay Compensation strange behavior on Pro Tools Ultimate

[Third Eye Studios]

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.

HDx with Lynx Aurora/LT-HD and Aurora (n)/LT-HD2 are sample accurate and identically emulate Avid interface latency. No manual adjustments needed.

[SaschaP]

It would be really great to cull together a list of both digilink and 3rd party interfaces that report correct insert delay times to Pro Tools.

I have been scraping the internet for a while and it’s really hard to tell what works and what doesn’t. For instance the Focusrite Red interfaces are not sample accurate even via digilink.

[Darryl Ramm]

Originally Posted by SaschaP

It would be really great to cull together a list of both digilink and 3rd party interfaces that report correct insert delay times to Pro Tools.

I have been scraping the internet for a while and it’s really hard to tell what works and what doesn’t. For instance the Focusrite Red interfaces are not sample accurate even via digilink.

AFAIK Digilink interfaces do not report any latency data, I suspect the latency is hard coded in Pro Tools for the interface. Certainly there appears no way for Digilink clone interfaces with different latencies to report their actual latency. That would be oh too easy. If Focusrite wanted "HD IO" accurate latencies they would need to do what other vendors do and produce interfaces with the same exact latency, or if lower latencies then add delay in the product.

I expect almost all CoreAudio Interfaces report accurate latency data, with maybe some concern about sloppiness in the industry of whether CoreAudio per-steam latency data is reported or is used. OTOH users get themselves confused here and it's sometimes what they are doing not the interface. I am writing a utility that will print out all the reported latency data (buffer, hardware, stream, and safety offset) data for CoreAudio interfaces. Stepping through all the nominal sample rates for the interface. I keep getting distracted and not finishing it off, it's not really for general use but if anybody is interested in an early very rough play with it and will give me feedback PM me. CoreAudio only, no ASIO support. Should be able to run on just about any Mac, or I can get it running on them if needed.

Interfaces can't know and can't report latencies for anything involving outboard (e.g. ADAT, AES/EBU or MADI conversion) and that is one thing that trips up folks and results in negative time corrections, although they should be relatively small. And no manufacturers I am aware of bother to report different (lower) per-stream latencies for interfaces that have both analog and digital connections, even when they have those interfaces divided into different streams (like RME does for some interfaces)--but then doing so is not likely a help and may be more confusion... you'd get sampel accurate behavior for pure digital paths, but again have latencies anytime a converter is required.

Measurements for multiple RME interfaces (Fireface UFX+, Madiface, Digiface), at multiple sample rates comparing their actual measured RTE time and sum of all the reported latencies they report from the driver are sample accurate. But same seems true for quicker tests on other interfaces.

And again, yes Pro Tools needs to add a ping feature (and it needs to be better than the UX mess in Logic Pro), utterly embarrassing that is not in the product. But there should still be usable today with a combination of insert latency (+ve values only) and track delay comp offset (where -ve values are needed). And the driver reported latencies that Pro Tools uses here to should help to give a close setup. If it's repeatedly not working for trivial insert setups then I'd love somebody to run this utility on that and see what the driver is reporting (it might be wrong or Pro Tools might not say calculate things properly where there are more complex setups, like multiple CoreAudio streams reporting different latencies (or heck a stream reporting any latency since most drivers report 0 stream latency and add any steam latency into the device latency etc.). Any case where there are very large offsets I do not suspect the driver or Pro Tools and more expect a session routing error, but again seeing exactly what the driver reports would be a good start.

[BScout]

My guess is Dante (due to network packets) is also one that has a hard time reporting fixed latencies. Which would impact the Focusrite Red line.

[Dax Productions]

Originally Posted by Darryl Ramm

ADAT, AES/EBU or MADI conversion) and that is one thing that trips up folks and results in negative time corrections

This isn't really what I'm seeing people talking about when it comes to negative offsets. It seems like this is an issue for lots of people (myself included!!) where just a simple out/in roundtrip from an analog output to analog input on the same interface, with no "complex" digital connections, reports an incorrect round trip and results in negative offset. I wish my problem was that I just needed to simplify, but I'm making it as simple as I can and still getting the negative offsets.

[Darryl Ramm]

Originally Posted by Dax Productions

This isn't really what I'm seeing people talking about when it comes to negative offsets. It seems like this is an issue for lots of people (myself included!!) where just a simple out/in roundtrip from an analog output to analog input on the same interface, with no "complex" digital connections, reports an incorrect round trip and results in negative offset. I wish my problem was that I just needed to simplify, but I'm making it as simple as I can and still getting the negative offsets.

I said that's *one* thing. It is unlikely to cover other cases with offsets > ADC conversion times.

You on Mac? I just offered you a tool that will report the whole array of latency data and should identify faulty drivers, and might identify faulty behavior by Pro Tools (say if it is not reading per-stream latencies correctly since the are a corner case that is not used by most drivers).

Can you share some of the test sessions and the number you are seeing with what interfaces (maybe you have already) when I've asked in the past for hard data like that folks have not shared them.

Again, every interface I've looked at, with my own tools, with Apple's HAL Lab and AU Lab report sample accurate latencies as measured by both RTL Utility and what I measure in Pro Tools and Logic Pro (e.g. if I measure latency and correct using insert offset or per track everything work out exactly). I think HAL Lab, and AU Lab can be downloaded without being an Apple developer, and RTL Utility sure is available to everybody. How about measuring stuff? And again I'd love folks who want to play to get early access to my tool. It will be buggy but it does report all the per-stream latency stats (again typically not used... but if a driver does report them what does that screw up?) and it automatically exercises all the interfaces at all their sample rates.

[Dax Productions]

Yes I’ve got RTL and responded in another thread, or possibly earlier in this thread, with my findings. Reported latency did not match measured latency.

[Jonne]

Hi,

I don´t know if this helps, but there is a "sum to zero" bug in Protools that prevents total cancellation when using HW Inserts. You are not able to get channels summed to zero with any of AVID units either (Have a MTRX studio as well as bunch of HD IO 16x16s). Already 2 years and counting with this bug.

So the only way to do this is, I would assume, is to use a summing mixer what Dax Productions suggested. Protools did use to be sample accurate with it´s own hardware before - and why I got MTRX studio. As it seems this is not going to be fixed anytime soon? I should´ve just got something else as AD/DA, as you´ll be needing the summing mixer anyways. So, doesn´t seem to matter what AD/DA you´re using - you´re screwed. :)

This happens on playback only by the way (works for some reason when bouncing / committing tracks). But, f.e. HW I/O parallel process distortion gives you different sound when you bounce the tracks, which really REALLY bugs the heck out of me!

------------------------
Customer Care 2020 : "We found a bug within Pro Tools that is not allowing a complete cancellation, and that this is not an MTRX Studio Issue, and would I like you to know the bug number (PT-265901) that it is under review with product management."

Customer Care 2022 : "I could see that you're follow up on this Feature request to apply insert delay in either units of milliseconds or samples.
The PT-265901 is still open and no ETA of implementation as of yet.
I'll be endorsing your case to our colleagues in EMEA to give you further updates on this." (in 2022)
------------------------

Turned to a bit of a rant. Sorry for that. With this midi mess on the latest 2022.6 is raising all kinds of feelings in me.. :)

[Darryl Ramm]

Interesting. Certainly for all the testing I've done it's only looking at what HW insert delay is, what the automatic comp is doing (based on what the latency data the CoreAudio driver advertises), etc. and for that everything I can test has been sample accurate. Would love to find cases where it is not.

Hardware insert latency measurements are made from signal leading edge zero crossing point. And automated RTL utilities effectively do the same, they don't try to cancel a signal. What is going on here in this bug might be interesting to know. As would finding any interface that does not properly advertise it's latency data and/or that Pro Tools for whatever reason misinterprets.. if that is happening.