Pro tools Studio hardware inserts - Weird latency issue with plugins

[flandybob]

Edit: for the actual bug description / video demonstrating go directly to page 2 / post 11

Hi,

Long time lurker, first time poster. Hopefully I'm on the right sub-forum.

I'm running into an issue I'm having trouble understanding. I just got an Apollo Duo Silverface with a thunderbolt 3 card and using Pro Tools Studio 2022.7.

I want to use some hardware outboard (in this case a klark teknik 1176).
I have configured the Apollo console and pro tools I/O and have left the "H/W insert delay" as default to 0ms for each input.

I created a little test session (44.1 KHz / 1024 buffer) with an audio track with a recorded PT click on it + a duplicate.

To my (pleasant) surprise, If I add my hardware insert on the duplicate, everything stays perfectly aligned, the latency compensation engine works (reported latency of 2382 samples)

If I add plugins to the original track (the one without the hardware insert) or before the hardware insert on the duplicate one, everything stays aligned. Same with using the hardware insert on a parallel aux channel.

Now the issue I have:
- whenever I add a plugin after the hardware insert, the delay compensation goes off and I hear a significant delay.
- It doesn't matter which plugin I use, even a 0 latency plugin like avid eq1
- If I use a higher latency plugin, for example UAD ATR which has 3350 samples of latency, the delay stays the same.
--> it always delays an additional 2048 samples. Looks like double my current buffer of 1024 but this value stays the same even if I use a lower buffer

To be honest I'm not sure what's happening, the delay compensation seems to work as long as don't put any plugin after the hardware insert.

Is this "normal" behaviour / am I missing something obvious / is this a pro tools bug?

Any help appreciated, cheers!

[albee1952]

Opinions vary on this, so here's mine(and please take it as opinion and not gospel): You are jumping thru hoops to use a very cheap piece of hardware, when any number of plugins will do the same job, and many will do it better. Consider the UA plugins you should already have as they are considered among the absolute best. That solves your problem, but having said that, I'm not telling you not to use the hardware. I'm suggesting that it be used(judiciously) on the way in(while recording). When I ran a commercial studio in Nashville a while back, I had some similar and some much higher-end hardware in my rack. I also had everything in place to use hardware inserts, with everything fully tested and delay fully compensated for. In the 4 years I had that system running, after initial testing and troubleshooting, I used hardware(during a mix) exactly zero times. But, I used all of it while tracking, with great results. Just food for thought

[flandybob]

I’m 100% aligned with you, I use UA 1176 plugins quite a bit and do keep the KT for light tracking compression.

Regardless of the actual gear used as hardware insert I would like to understand how to fix the issue. I hate not knowing why something doesn’t work as expected!

And maybe down the road invest in better outboard gear. But before I do this I want to make sure I can make it work, hence the post :)

The other piece of gear I have is a sansamp RBI which I like quite a lot, there’s actual value in putting recorded DI bass through that. The way I do it currently is using hardware I/o and tweak the sound, then print and further process. What would be cool for me is to be able to further process the track with plugins and when I’m confident the RBI is setup ok, then print/commit. Currently I can’t do that because of the latency issue

[Darryl Ramm]

It's unclear to me what exactly you are describing. When you see unexpected behavior with a plugin after the HW insert, is it the reported latency comp value that seems wrong? But the delay comp applied to the signal seems correct? Or is the signal offset in time in ways that make the latency comp look like it was applied wrong? When you say the "delay comp goes off" what exactly do you mean? It seems to be disengaged? It actually does disengage (is unchecked? in Options>Delay Compensation). What colors are all the comp delay values in the Mix window latency display? When you hear a difference are you monitoring what is happening live or listening back to what was recorded through the inserts/plugins?

I tried and I could not reproduce any problems related to this. Either in 2022.5 or 2022.7 on Monterey on an Intel Mac. Intel vs Apple silicon is very unlikely to make a difference. I tested with my trusty RME UFX+, a straight through cable hardware insert and the EQ3 1 freq plugin before and/or after the insert.

I see exactly what is expected with hardware inserts and plugins installed before or after the insert. Both with an unchanged delay comp # samples value showed for those tracks, and with actually observing a click waveform being correctly compensated (I split a sample accurate click on two tracks and routed one on signal direct to a bus and the other out through the insert and plugins and get a sample/phase accurate reinforcement of the signal and combined them back on a bus again. Latency due to the insert is the expected 285 samples at 44.1 kHz and 385 samples at 96 kHz (both @ 64 sample IO buffer size).

One suspicion is you have a routing problem or corrupt session, maybe something in your routing problem is triggering a bug, maybe it could be something you are doing with the UAD Console. Try getting rid of all sends and aux tracks if you are using them now in that test session.

Can you share your session... e.g. zip it up and put it on a file sharing site and post the link here.

Seeing a fixed latency of 1024 x 2 samples raises suspicion you are seeing an effect of the fixed size disk buffer. That buffer is 1024 samples at 44.1 kHz. One thing you can try is to run a session at 96 kHz (where I think the disk buffer increases to 2048 samples) and see if you see that larger value in whatever you are seeing. I'm not sure it changes to 2048 samples at 96 kHz, just try increasing sample rates until you see a change.

And I agree with what Dave is raising, I just don't see any reason to use a Klark Teknik as a hardware insert when you have high-performance beautiful plugins that are simple and easier to use, and will perform as good or better. [just saw your reply, yep agree with your sentiments there, only other comment is when checking out insert issues it's a good idea to just use a straight through cable].

[flandybob]

It seems like I'm too much of a new user to post long replies

I'll try to sort this out and get back on topic!

[flandybob]

To clarify:
- when I add a hardware insert on a track, I can see in the mixer that the hardware loop latency is reported on the track at the bottom (2382 samples) = track is aligned with the rest of the session

- if I add a plugin directly after the hardware insert, an additional 2048 samples is added which generates latency. For example if I add avid eq1 which is 0 sample latency, the resulting latency reported at the bottom of the track in PT mixer becomes 4430 = track becomes out of time with the rest of the session (which is what I meant by "delay comp goes off")

I tried changing the buffer size but not the sample rate.
Changing the buffer results in a lower latency from the hardware insert (don't remember the actual value but lower than 2832 samples, which makes sense) but the additional 2048 samples stays the same after adding a plugin.

I attached my test session. Sorry it’s messy because I tried a bunch of stuff. The way it’s currently setup:
- track 2 (click raw.dup1) has and audio click track and is sending to Aux 1
- track 3 (Aux 1) has the hardware insert + UAD ATR 102 after

edit: with the link to the file https://drive.google.com/file/d/1-Rl...ew?usp=sharing

I have my eyes on the Tegler creme and some other stuff way better than the Klark Teknik, just want to make sure I can actually use the stuff before going down that road.
Agreed on using a straight cable, but since it works as it should when there's no plugin after, I dismissed this being a factor.

[Darryl Ramm]

Uh just what are you doing?

Yes I asked you to share a session so other folks here can see what you are seeing, and appreciate you trying to do that but I expected you to pack up something super simple that actually shows what you are describing. Not the mess you shared. I expect one or two tracks and use of say one EQ3 plugin. And no sends (I already flagged they may cause problems). And really should have cleaned crap out of the test session, fully delete unused tracks, delete busses with custom unclear names etc. and you have something like 5 different busses being used???. Get rid of all of that crap. Heck ideally delete any IO you don't need to demo the problem, since others are going to need to map it to their own IO. And the plugins are UAD plugins... few folks here have UAD plugins, and you already said you reproduced this with a core Avid plugin. So why are you sharing a test with UAD plugins?

And even looking past that I don't see what you describe when I load the session. Maybe there is a problem opening the session but there is nothing driving the Aux1. Track 2 "click raw.dup1" is output to A MON L/R it's not driving Aux 1.

I worry that the mess that this test session reflects what is going on in your thought processes. You need to clean this mess up. And at least have what is going on in it match your description in this post. One or two tracks. One hardware insert. One EQ3 plugin. I expect to add or remove that plugin and see crazy increase in latency compensation value reported on the track. That's should be what you have in a test session actually able to reproduce the weird behavior you are describing.

And in addition to just being a mess, you have a high-latency UAD ATR-102 plugin after the hardware inset. That plugins adds 2262 samples of latency at the 44.1 kHz sample rate you are running at. The ATR-102 can also have additional delay setup inside the plugin, but that extra delay should not get reported to delay compensation. So what are you doing here sticking that plugin after a hardware insert? Of course that is going to add significant latency. And since you are playing with an ATR-102... are you wanting to use hardware inserts on a mastering bus? Then you don't need hardware compensation at all.

And in those other tracks in the session you are not using, not sure what is going on there, using a send to hardware output etc., I can imagine you are testing something, but that's not how you do a hardware insert, you should be focusing on the standard simplest use of a hardware insert in the most trivial session and showing that works as expected, just get all that other stuff out of the session.

And if I clean up all the mess in your session, use the recorded click on a mono audio track and route that to an aux with a hardware insert on it like you were. Everything behaves exactly as expected. I see the exact latency I expect to see of 221 samples at a IO Buffer size of 64. (RME Fireface UFX+ at 44.1 KHz using analog line hardware inserts). Adding and removing EQ3 1 band plugin after the hardware insert makes no difference. And this correct expected behavior happens if I route the output of the pre recorded click track to the aux via an explicit internal bus or to the named track.

Screenshots show the tracks and expected latency values in the mix window...

If you can show what you describe in a very simple session *please* share it and it will get looked at and will get escalated if its an actual bug.

[Darryl Ramm]

Here is your session simplified, it shows no insert/plugin related latency problems for me.

https://drive.google.com/file/d/1idM...ew?usp=sharing

I assume there should be no reason to use an audio track vs click track to drive the aux, but I left the same audio track you were using.

After opening your original sessions on my computer I noticed the internal busses seemed messed up. Bus I/O options were greyed out on all tracks. Defaulting *all busses* fixed that. Not sure if that's just opening a session on a different box or if your busses are messed up. But again I don't see anything behaving a unexpected, if I route to a bus or to a track, I left the test session using a bus.

[flandybob]

Hi,

Thanks again for taking the time. I think I should have not sent that session and just waited for my gear to be available again so I didn't waste your time!

When everything is in order on my side, I'll run my test session again and provide screenshots on what I'm actually seeing. Easy enough to explain when you are in front of the session but somewhat difficult to write down.

I opened the test session again and have leftover busses from a full session. Should not impact the results I'm getting as I'm not using any of them but I'll run this again from a clean one.

Cheers!

[Darryl Ramm]

OK great, get stuff to me when you can, a clean session and screenshots would be great and just using core plugins. And remember I'm suspicious that you are seeing some bug due to the fixed size disk IO buffer, something that may be related to paths that does not route to a monitor out (and therefore is not considered "low latency" by Pro Tools and that would use the adjustable size IO Buffer size, so keep routings simple, don't use sends etc.).