Hardware delay comp ahead lynx

[pherzfeld]

Reviving this:

Im using 2x Lynx Aurora (old) with LT-TB card in each.

I experienced the same thing.
Created a new session. Created an audio track with a click track printed. Added hardware insert to this track, bussed to new audio track, and printed. Destination track is 17 samples EARLY compared to the source track.


I emailed Paul at Lynx tech support. He said Pro Tools compensates for the latency reported by the Aurora, and this is a fixed number of samples based on the sample rate and physics of the a/d/a roundtrip. Its not possible that the Aurora is reporting incorrect conversion delay times. Its only possible that Pro Tools is not receiving them, or isn't looking for them often enough, or something. He said that often times this issue is caused by a plugin somewhere in the session reporting incorrect delay times. That makes sense, but my fresh session had no active plugins when I conducted this test.

I found that quitting pro tools and starting it back up solved the problem. Everything was sample accurate.

I also found this -
I opened an existing session and added a hardware insert to a track that already had plugins assigned. I bussed the track to a new audio track and printed. The destination track did not align with the source track. I deactivated plugins on that track one at a time, reprinting between each one until I found the culprit. This resulted in a sample accurate print.

Reactivating the plugin brought the problem back, but by removing the plugin and reinstantiating that same plugin the problem did not return. Im not sure what to make of that, but I recreated the same issue over and over again on different tracks in the same session, resolving them the same way each time.

[Darryl Ramm]

Computer? OS details?

You are using these Aurora together via aggregate I/O? How are the clock synced? Since aggregate I/O has lots of issues at times, what happens when you repeat this with one Aurora that is not a part of an aggregate?

What exact I/O ports are you using on the Lynx for the H/W insert? Is this an insert between line level analog I/O ports or between digital inserts (including if you say might are using S/PDIF or be going out to an outboard ADAT I/O etc.)?

Pure digital H/W inserts are expected to be at negative time offsets, 17 samples might seem reasonable is so (and you correct in that case with the track +/- delay comp setting). Depends on sample rate and details.

What happens when you measure with no plugins and only a H/W insert on a track? And with LLM NOT enabled.

There is a known bug where a software insert (plugin) following a H/W insert with LLM enabled. PT-293686 This, at least in the known failure mode causes a large (1024 or 2048 sample) incorrect calculation of delay compensation and as that is applied a matching incorrect offset that is awfully audible. Any time you quote a sample delay/offset you need to tell us the sample rate you are working at.

Can you describe exactly what you are doing (ideally starting with a new empty session) with the plugins etc. to reproduce a problem, what exact plugin and in what order to show a problem. If you need to share a test session. What exact offsets are you measuring ? -17 samples in all these cases? With all sample offsets/delays measurements please tell us what sample rate you are working at.

[Jonne]

Dax, this also happens with AVIDs own IO hardware as there is a bug. It´s been there at least the last 2 years when I reported it. Does not matter if it´s HDX, Native, MTRX or just AVID16x16IO. I can´t understand why people are not furious about this! The most fun thing is that when mixing (realtime) you get the crazy comb filtering while parallel processing, BUT when you bounce a track or the whole mix = everything is correct (and hence different than what you hear on playback). And that is the why I´ve been using other DAWs lately, as I don´t think this will be fixed anytime soon..

Originally Posted by Dax Productions

Darryl this is the problem. 20 samples is pretty close. It’s close enough that I can insert something on a one track instrument and not be worried at all. I have my 1176 on my vocal bus on every mix I do. In my case it’s 62 samples early at 44.1. Not enough to sound out of time, and for that situation I don’t have to worry about comb filtering with parallel elements.

The problem is as soon as you want to do any parallel processing. 20 samples will have bad, glaringly obvious comb filtering if I want to use my adr compex as a drum back buss. It needs to be zero samples.


I did try the RTL app and it does confirm that the driver reported latency is slightly more than the actual recorded latency. 62 samples at 44.1, and similar, but not far off numbers for other rates.

My current interface is a Behringer 1820 but I have had similar “over compensation” with UA, Motu, and focusrite interfaces.

[pherzfeld]

Originally Posted by Darryl Ramm

Computer? OS details?

2013 Mac Pro Quad Core
OS 10.15.7
Pro Tools 2022.10
LT-TB Firmware 6.5 Driver Build 58K
Aurora Firmware 28

You are using these Aurora together via aggregate I/O? How are the clock synced? Since aggregate I/O has lots of issues at times, what happens when you repeat this with one Aurora that is not a part of an aggregate?

The two converters are connected through word clock. Yes Im using them as an aggregate device. Is there a better way to do this?

What exact I/O ports are you using on the Lynx for the H/W insert? Is this an insert between line level analog I/O ports or between digital inserts (including if you say might are using S/PDIF or be going out to an outboard ADAT I/O etc.)?

All connections are line level analog connections. No ADAT, AES, or S/PDIF is in play anywhere in the room. My compressors are normaled to I/O 25-32 (Lynx B I/O 9-16)

Pure digital H/W inserts are expected to be at negative time offsets, 17 samples might seem reasonable is so (and you correct in that case with the track +/- delay comp setting). Depends on sample rate and details.

At 48k the print arrived 7 samples early. At 96k it arrived 17 samples early. All analog connections on the lynx. See my video link and reply below - I have more detailed info now.

What happens when you measure with no plugins and only a H/W insert on a track? And with LLM NOT enabled.

Im not using LLM at all. Again, see below for video link and more info related to sample rate changes.


There is a known bug where a software insert (plugin) following a H/W insert with LLM enabled. PT-293686 This, at least in the known failure mode causes a large (1024 or 2048 sample) incorrect calculation of delay compensation and as that is applied a matching incorrect offset that is awfully audible. Any time you quote a sample delay/offset you need to tell us the sample rate you are working at.

Can you describe exactly what you are doing (ideally starting with a new empty session) with the plugins etc. to reproduce a problem, what exact plugin and in what order to show a problem. If you need to share a test session. What exact offsets are you measuring ? -17 samples in all these cases? With all sample offsets/delays measurements please tell us what sample rate you are working at.

Heres an update. My original issue of tracks printing early by a few samples was resolved by restarting Pro Tools. My real goal here is to understand what I'm doing wrong so I don't inadvertently recreate this scenario at the worst possible time.

My issue now is that Hardware delay compensation seems to behave differently when different sessions are opened - but I figured out the pattern and its predictable - and its all tied to the clock sample rate BEFORE Pro Tools is opened.

Whatever the converter sample rate is set to when Pro Tools is first opened - this is the sample rate that Pro Tools is basing hardware ADC on EVEN IF YOU OPEN A DIFFERENT SESSION WITH A DIFFERENT SAMPLE RATE. To get correct ADC at a different sample rate you have to quit pro tools and reopen it with the converter clocked to the correct sample rate before you open pro tools. I made a video to demonstrate.



https://www.dropbox.com/s/9hy5oebhsp...%20PM.mov?dl=0

This video shows two fresh session - one at 48k and one at 96k
Each session has a printed click track bussed to an audio track. The source track has a a hardware insert.

You can see that when the Lynx is set to 48k before pro tools starts that the 48k session compensates correctly, but when switching to the 96k session it does not compensate correctly.

The opposite is true - setting the converter to 96k before starting pro tools and opening the 96k session - compensation works correctly, but when switching to the 48k session it does not.

Side question - what's all that distortion on the destination waveform at 48k? Its not from a piece of hardware in bypass - I have this insert patched straight AD-DA on the patchy.

[Darryl Ramm]

OK very neat, thanks for the explanation. An off the cuff guess here/first thing to exclude is if Pro Tools is using the latency data from the driver but getting it for the wrong sample rate. Might be a Pro Tools bug, might be a Aurora driver bug. Both are worth trying to reproduce or exclude.

To get some raw hard data would you mind downloading Oblique Audio's Latency Tester. https://oblique-audio.com/rtl-utility.php. Then with no other DAW or software accessing your Aurora can you run that at both (edit:) 48 kHz and 96 KHz. And share back both what it reports for the driver values and the ping value. This is very likely a tool that Lynx' and Avid's developers will use. The "Reported" RTL latency comes from summing together several latencies reported from the Aurora CoreAudio device driver, and is the same data Pro Tools uses to provide automatic delay comp on H/W inserts as well as transparently compensate general input and output latencies.

It might also be that the Aurora driver is having some problems here reporting the correct latency, there seems to be a number of Lynx users who have reported H/W insert latency problems. Maybe you can try changing the interface sample rate and check that the driver reported latency always changes. I hope you should be able to keep this utility open and use it to see if the reported latency changes when the sample rate does... Try clicking on the "Measure RTL" button just after you make the sample rate change there might be a small window/time error here that you'll have to be very lucky to catch... there is another way that might capture stuff better (grab the coreAudio sampel rate change message and immediately get a latency report at the driver) but I'd have to modify a program I have, and that's not going to happen quickly.

[Darryl Ramm]

Originally Posted by Jonne

Dax, this also happens with AVIDs own IO hardware as there is a bug. It´s been there at least the last 2 years when I reported it. Does not matter if it´s HDX, Native, MTRX or just AVID16x16IO. I can´t understand why people are not furious about this! The most fun thing is that when mixing (realtime) you get the crazy comb filtering while parallel processing, BUT when you bounce a track or the whole mix = everything is correct (and hence different than what you hear on playback). And that is the why I´ve been using other DAWs lately, as I don´t think this will be fixed anytime soon..

Do you have a bug number for this?

Some folks are furious about latency comp issues with H/W inserts but many are not... likely because for them it works as expected. I was having zero problems getting sample accurate H/W inserts on my RME rigs with Pro Tools .. until folks worked out how to reproduce some problems, and then I could mess up deliberately (and used that to help file bugs with support). We've had some great cases of folks finding weird ass corner cases that trip up things. Like the LLM and a plugin following a H/W insert bug PT-293686 that has likely been around for ages, and cause lots of pain for folks here in the past but nobody could get a handle on it until one user persisted in how to reproduce it. Still not fixed, but Avid Support said it's getting fixed "as soon as possible" (yes I know... but at least it's in the system).

And on the other side it's clear that some frustration here about latency comp on H/W inserts comes down to user understanding, and some of the doc is a little misleading and UI confusing. This is especially true where folks try to use digital outboard gear or ADAT I/O including on Pro Tools Digilink setups.

What does not really help advance improving stuff is thinking H/W insert latency comp "is all broken". It's not, it works for many users. But it clearly has problems, clearly needs Avid developer attention, and the sooner all those problems can be found/reproduced/documented/fixed the better.

[s.d. finley]

Lynx doesn't use the core audio TB diver as it does the USB? Is that a thing? TB Core audio driver?

[pherzfeld]

Heres the log file so far

[Darryl Ramm]

Originally Posted by s.d. finley

Lynx doesn't use the core audio TB diver as it does the USB? Is that a thing? TB Core audio driver?

Huh?

It sure uses a CoreAudio driver... and that connection is via Thunderbolt, it might be a variant of a PCIe driver. But you can't aggregate their interfaces like they talk about unless it's all CoreAudio.

[killah_trakz]

My issue is honestly bus related. I cannot do ANY parallel work what so ever with hardware. I had to leave protools and finish working.

They need a ping function period or allow negative delay in the I/o section.


Sent from my iPhone using Tapatalk