Pro Tools Studio 2022.9 problems. Please help me

[Simonluka]

Hi bros,

sorry if you already spoken about these, but I have a couple of problems with Pro Tools that I can't fix. Hope you can help me.

I use Pro Tools Studio 2022.9 on Big Sur with Audient interface to which I connected a Lucid 88192 converter (8 channels) via adat.
Then I connected two hardware mono compressors (identical) to the In/Out of the Lucid (channels 7 and 8)

In the "I/O" menu there is an offset between IN and OUT channels, so I can't use the compressors as inserts on channels (pro tools wants the inputs and outputs to be the same .... Damn!), so in the project I created two mono Aux tracks by setting the inputs to Adat 7 and Adat 8 (the ones where I connected the two compressors) and the outputs of these to Main Output.

I imported a mono audio track and set the out to a "dead" bus and I created two unity gain sends to Adat 7 and Adat 8.
The signal goes into both compressors and everything seems ok, BUT:

1) Raising both sends, I notice a “flanger” (phasy) effect, as if the two signals were not aligned.

2) If I activate only one send to one of the two compressors and print the result on a new audio track, I have a delay between this and the original one.
I calculated this difference in milliseconds and entered this value in the compensation hardware menu.
This does not affect anything and the printed signal continues to have the exact same delay

Can you help me?

Thank you and sorry for my bad english

Simonluka

[LDS]

I suspect it is a bug in 2022.9. I have had similar experiences with settings within the Avid audio engine being 'stuck'. The native sample buffer in my HD native system doesn't have any effect in terms of latency, for example.

You could try filing a support ticket. Though I did that 10 days ago and it is still sitting in a queue...

[Simonluka]

Originally Posted by LDS

I suspect it is a bug in 2022.9. I have had similar experiences with settings within the Avid audio engine being 'stuck'. The native sample buffer in my HD native system doesn't have any effect in terms of latency, for example.

You could try filing a support ticket. Though I did that 10 days ago and it is still sitting in a queue...

Thanks for your answer bro.
For example Cubase does not have this problem and it's absurd that in 2022 Pro Tools still has problems with the use of hardware...
And also the fact of not being able to use them as inserts because the in/out are not matching...
Bah....

[Simonluka]

Originally Posted by LDS

You could try filing a support ticket. Though I did that 10 days ago and it is still sitting in a queue...

I am trying but it is IMPOSSIBLE (thousand errors, form that freezes)...
What a shame!

edit: ok, done

[albee1952]

1) Raising both sends, I notice a “flanger” (phasy) effect, as if the two signals were not aligned.
Okay, don't guess. Are the two signals aligned or not(easy to check with Tab to Transient if you print the audio)? What compressors(maybe it matters)? Might one of them be reversing polarity(mis-wired unit, or by a bad cable)? Opinions vary and here is mine; if the 2 compressors are something very special, keep digging and I hope you find a solution. However, if they are some "budget" models, skip the hassle and use plugins(but do use them while tracking by routing thru them on the way in, which negates any hardware insert issues)

[Simonluka]

Hi Albe, thanks for your answer.
Cables are ok. I din't stamp, but I just heard the "phasy" sound....
Compressors are not so special, but I did the test with two Burl B1 (preamp) too and the result is the same...
Anyway I received an answer to my ticket from Avid (very fast, great!) and I'm doing some tests...
But now the printed signal (just un tone send to a new audio track) is some samples earlier than the source one (?!?!?!?!).
It's amazing how there is always something that doesn't work right ...

[albee1952]

Originally Posted by Simonluka

It's amazing how there is always something that doesn't work right ...

Exactly the reason for my suggestion

[Darryl Ramm]

Lots more clear info on exactly what you are doing/seeing would help you get help.

What exact interface are you using? An Evo 16? ID44? Something else?

What exactly shows up in the input, output I/O pages settings? Post a screen shot (see how below). If it's an ID44 or Evo 16 I am surprised you cannot get two ADAT IO ports connections that line up to use a hardware insert.

Start by making stuff easier by using straight through analog cables. No external H/W boxes.

What is your IO Buffer size, sample rate and measured latencies in samples (not ms) -- that will often give an idea what different latency causes are.

When you start routing audio via sends there is increased likelihood of doing something that trips Pro Tools into signal paths where the disk buffer is used not the IO Buffer. That buffer is 1024 or 2048 samples depending on sample rate, and not affected by the IO Buffer setting, if you see latency numbers like that or 2 x that then that's a clue that you've got routing that is causing the use of that disk buffer.

I still can't visualize the routing here. Maybe you could post screenshots of your mix window (showing inserts, sends, and I/O selectors) and IO setup pages. Share them on a file sharing service and put links here, don't directly attach them on DUC they all get downsampled so much we can't read them clearly. Or maybe draw a picture of how stuff is exactly routed and share a photo of that.

As I and others have explained multiple times on DUC: Negative time offsets are *expected* when you use digital I/O inserts on mixed analog/digital interfaces. Pro Tools corrects for I/O latencies using it's buffer size and information provided from the interface device driver. An interface with both analog and digital (like ADAT) interfaces typically provide latency data the suits their analog input and analog output channels. When I say typically... read that as always, and although it's possible for a driver to provide difference latency data for different I/O ports (streams in CoreAudio parlance) no driver manufacture I am aware of does that, and no DAW I am aware of assumes it's possible.

So if you play with inserts (or pretend inserts like it sounds like you are) Pro Tools is delay compensating using latency data for its analog I/O, the digital I/O you are actually using will be faster and so will appear at negative time. Other DAWs will do similar when relying on the driver provided data. But other DAWs also provide ping utilities and easier ways to set negative offsets by hand than creaky Pro Tools does.

In Pro Tools you can deal with these negative offsets by adjusting the track delay compensation +/- value in the track delay comp settings. There is no reason these cannot be handled for any sane setup/session/routing.

When you say a signal is earlier... by how much *exactly* in samples?

[Simonluka]

Hi Darryl, thanks for your kind reply. I try to explain more precisely.
You can download the photos I quote below at the following link:
https://we.tl/t-jyUIglpB7l

I use an Audient ID44 (1 series) to which 2 Lucid 88192 are connected via adat.
In Pro Tools, I always work on 44.1/24-bit projects.
In the Options menu, I have delay compensation enabled and Low Latency Monitoring disabled (photo 1)

As suggested by Avid support, I disabled “Ignore errors during playback / record” on the Playback Engine window (I unchecked both “Main Playback Engine” and Aux I / O, even if I don't know exactly what they are for ...)
The Buffer Size hardware is set to 1024 (Photo 2)

To make things simpler, I removed the hardware gears (compressors) and directly connected input 1 to output 1 and input 2 to output 2 of the Lucid via two separate analog cables (photo 3).
For convenience, I use the second Lucid 88192 (connected to the second adat port of the Audient) because it is more easily accessible.

In the I/O setup window, I set “default”. Although I would be happy with that, I cannot use gears as “inserts” on channels (as plugins), because I would have to have the same inputs and outputs (it's a Pro Tools problem that I don't have with cubase for example...)

Instead in my case (considering that the Audient has 4 inputs and 8 outputs) the subsequent I/O adat will be staggered (Photo 4 and Photo 5).
In fact, channel 1 of my second Lucid unit (which here is called “SPDIF3 / ADAT…”) has input 13 and output 17 (Optical).
This forces me to set the output of my audio track (or the send) on "Optical 17" (Output 1) and print to another track (perhaps with input adat 13? It's not clear for me ).

So I created a mono audio track with a 1KHz tone at -18dBFS and set the output on a "dead" bus, so as not to hear anything on the main out (Photo 6).
On this I created a send to “Output 1” (Optical 17 of the I/O Setup menu) set to Unity gain (Photo 8).

Then I created another mono audio track ("Audio 1") and set its input to "SPDIF-3 / ADAT- /SPDIF-4/ADAT-.L" (Photo 9).

I did the print on this track which is earlier than the source track (Photo 10). It can also be understood by looking at the end of the track just recorded, which ends early (Photo 11),

I created an additional mono audio track ("Audio 2") and I set its input to "SPDIF-3 / ADAT- /SPDIF-4/ADAT-.R" (Photo 12) and on the source track "Tone 1 Khz" I did a send to Unity main towards Output 2, i.e. Optical 18 (Photo 13). Yes, this one is identical to the other, equally anticipated (Photo 14).

The Delay value on the channels is always equal to zero (Photo 15) and the advance seems to be 33 samples (Photo 16).

Now, fortunately, I no longer have any delay (maybe because I disabled "Ignore errors during playback / record" as suggested by Avid support? I don't know, also because I don't quite understand what is the purpose of enabling these two boxes ...
But now I have an advance that creates the same phase problems (if I send the tracks on several outputs connected to gears, it is a problem ....).

Thank you all for the help and for any suggestions!

[Darryl Ramm]

Lets start with you not using H/W inserts. I do not understand why you are not using them.

Pro Tools requires the physical I/O port numbering of an insert to match. Not the I/O port names... those are pure symbolic labels for us humans. If they bother you you can change those to anything you want.

So here you could pair up say I/O Port 10 as an insert. That's ADAT 6 Input and ADAT 2 Output if I'm reading your I/O pages correct. It shows up in the I/O > Inserts as "Insert 10". But pick what works for you and set that up. Start changing the names of the ports if that helps you track what is connected to what.

I would have hoped Avid support would have got you working like this as well, this is a case of doing things the "right way" ends up being simpler in the long term.

So can you work on getting that sorted out. Play with changing I/O port and insert names.

[EDIT: corrected the following, was posting late at night]
33 samples at 44.1 MHz... that is in the right ballpark and completely believable. This comes from the ADAT internal converters having less latency from ADC on the input and the DAC on the output compared to the onboard converters used in the analog H/W inserts. There is no way over ADAT (or S/PDIF, or MADI, or ...) for a converter/preamp to advertise it's input or output latencies, so the interface can't know what it is and its driver just advertises its own internal analog I/O latencies. On my RME Fireface UFX+ I see ADAT H/W inserts 17 sample latency ahead @ 44.1 kHz when using pure ADAT to ADAT inserts (no analog conversion) compared to analog line H/W inserts that are sample accurate without having to do anything. RME has very low latency conversion for everything, different vendors/products/drivers will differ but they should have values kinda in these ball parks.

Now while you are playing around... you have analog ports on the ID44, so to confirm how stuff works you can create a H/W insert between two analog I/O ports with a straight trough cable and measure the offset with delay comp enabled (and "H/W Insert Delay" set to 0). You should see the compensation for that is dead on, to a sample.

You should always dive in and measure latencies, again what exactly the latency is will give you a clue what is causing it. Don't try to measure latency with a sine wave/signal gen signal. Use a click track signal and measure from the leading edge of the click or when the waveform crosses 0. With care you should be able to measure to one sample accuracy.

Edit: Once you have H/W inserts working (and measured to a sample or so accuracy) you can adjust negative offsets using the +/- delay compensation adjustment for the track the insert is on (*not* the I/O> "H/W Insert Delay" page).