I/O latency going bonkers

[Guilla]

Hello all,

Here is my problematic setup :

Mac OSX 10.12.1
Pro Tools 12.6.1 (non HD) - according to Avid this is the version to use on this OS -.
Lynx Aurora 16 (n). Latest firmware up to date. Working flawlessly.

I have an hybrid mixing setup.
I often use I/O insert in Pro Tools
Apart from the lack of Input/Output and dry/wet function (that any other DAW are offering now and it is not even available in PT HD), I am quite annoyed by the inconsistencies in term of latency with I/O insert.


I use the click technique to calculate the latency and enter it in the H/W delay compensation (print a click track, print it with I/O insert and outboard bypassed, calculate the latency etc...).

What drives me insane it's that it seems that I/O latency is never the same between sessions. Even in sessions sharing the same sample rate, buffer size and else.
Why?

Also, sometimes I/O latency is different in between different I/Os.
Like 9-10 need 46.44 msec and 5-6 is ahead of the source (!).

I/O being ahead of the original source is problem I had to face with my previous interface (Arturia Audiofuse Studio). Which is another thing that makes very little sense to me (even with HW delay set to 0). I remember that I tried to deactivating Delay Compensation and suddenly the printed I/O was way behind, but it created an obvious mess as plugins were not delay compensated.

I've seen this issue quite a lot in here in Duc, people saying that outboard I/O are printed ahead of the source. Or that I/O delays are never the same or very inconsistent.
And every time the answer seem to be something about blaming the audio interface company. In which case the OP contacted the interface company which said that it may be Avid's fault and then no real solution were offered.

I do feel that it is Avid fault, I am not getting this kind of issue in Reaper or Logic Pro X (but they have a ping function anyway, so it makes it much smoother, but Avid may never offer that as they wanna sell HD and Digilink cables and such, lol). But I wanted to create a thread about it in order to, ideally, find a solution to this once and for all, so people that paid good bucks for PT can at least get a bit of value out of it and not feel that they paid for something that is 10 years behind what other DAWs are offering on some basic features (I am glad I got my Pro Tools second hand for less than a Ibanez TS808 mini).

Thanks to everybody who will chime in this thread. Let's find a solution to this madness .

[Darryl Ramm]

Negative delay offsets can be understandable any time you have mixed analog and digital IO paths involved, heck they should often be expected. That might explain your past setups behavior?

There is a significant bug in hw insert behavior with LLM (PT-293686) that I and others have described clearly in other threads including those discussing Lynx problems. You using LLM? Switching it on or off between sessions? Changing "allow sends to persist"? between sessions? If so that could cause large (2k or 4k sample) incorrect compensation changes to appear/dissapear.

There multiple other delay comp related bugs floating around. But working around the LLM bug is the only one I need to worry about with h/w inserts on multiple RME interfaces that deliver consistent sample accurate behavior and have done in Pro Tools releases from years back to now. And correct consistent behavior here includes getting exactly to the sample the expected negative offset when working with digital IO paths.

Its interesting how Lynx users keep reporting problems... but none of you folks seem to have actually worked through the numbers/engaged with Avid and/or Lynx support to actually get to the bottom of this. Somebody at Lynx saying they don't have a problem is not really helping, even if they are correct they could roll up their sleeves and actually help look at the problematic behavior that multiple users seem to be having with Pro Tools.

Exact measurements of latencies will often provide clues to what is going on. If the interface driver is reporting correct latency data and if Pro Tools is interpreting them properly, and maybe timing windows around sample rate changes, are likely the key suspect here if there is something seemingly specific to Lynx.

All this has been well discussed in the past in other threads so I am not sure why you are creating yet another separate thread about it. I am not going to spend time further repeating stuff I have all said in detail before elsewhere.

[Guilla]

Originally Posted by Darryl Ramm

Negative delay offsets can be understandable any time you have mixed analog and digital IO paths involved, heck they should often be expected. That might explain your past setups behavior?

There is a significant bug in hw insert behavior with LLM (PT-293686) that I and others have described clearly in other threads including those discussing Lynx problems. You using LLM? Switching it on or off between sessions? Changing "allow sends to persist"? between sessions? If so that could cause large (2k or 4k sample) incorrect compensation changes to appear/dissapear.

There multiple other delay comp related bugs floating around. But working around the LLM bug is the only one I need to worry about with h/w inserts on multiple RME interfaces that deliver consistent sample accurate behavior and have done in Pro Tools releases from years back to now. And correct consistent behavior here includes getting exactly to the sample the expected negative offset when working with digital IO paths.

Its interesting how Lynx users keep reporting problems... but none of you folks seem to have actually worked through the numbers/engaged with Avid and/or Lynx support to actually get to the bottom of this. Somebody at Lynx saying they don't have a problem is not really helping, even if they are correct they could roll up their sleeves and actually help look at the problematic behavior that multiple users seem to be having with Pro Tools.

Exact measurements of latencies will often provide clues to what is going on. If the interface driver is reporting correct latency data and if Pro Tools is interpreting them properly, and maybe timing windows around sample rate changes, are likely the key suspect here if there is something seemingly specific to Lynx.

All this has been well discussed in the past in other threads so I am not sure why you are creating yet another separate thread about it. I am not going to spend time further repeating stuff I have all said in detail before elsewhere.

Negative delay offset, by that you mean the wet signal (I/O processed) sound appearing BEFORE the source?
Otherwise yes, I/O insert are meant to have delays, that is something I am used to. But the sound being BEFORE sounds more unexpected to me.

I am not using LLM at all. So that's out of the equation right?

Actually you jumped a bit too quickly on the Lynx issue if I may. As I stated, the problem was very similar if not exactly the same with my Arturia AudioFuse.
It was even more annoying on my Audiofuse as the wet I/O was constantly appearing ahead of the dry source. So I could not even use the HW delay compensation.
So Arturia and Lynx are wrong, but not Pro Tools? (I also remember having similar issue with an old Apollo Silverface rack interface, UAD were wrong too?).
Also if Lynx was faulty, I'd expect similar behavior on LPX or Reaper 6. And it is not the case afaik. I know that PT use a different architecture so it's kinda comparing apples to oranges. But when biting in one of them , I'd expect the apple and the orange to have a few stuff in common at least. If the orange taste like salt, I'd think it's the orange that is probably wrong. If you see what I mean.

I've actually read the other threads and did not found any solution in there. Actually most of the thread I read finished on a dead end. Like "Ah the interface calculate the latency properly, but Avid differently, so well... it is what it is...".
Or maybe the OP never shared their solution.

I also read someone saying that the interface need to be at the right sample rate before even opening Pro Tools to avoid this weird incoherence in delay I/O calculation. That's something I followed. But the delay I/O are still different on different sessions with exactly the same buffer size/sample rate etc... And restarting my computer each time I am opening another session sounds a bit insane.

You don't have to repeat what you already said, because I actually read it and found no solution, hence why I am creating this thread. Hoping to put an end to this phenomenon. It doesn't seem normal to me. I should at least get the same delay measurement at the same buffer size/sample rate every time.

Thanks a lot for the very quick answer by the way, this is greatly appreciated !

[Darryl Ramm]

Negative delay offsets when working with mixed analog and digital IO on an interface are easy to understand and I and others have gone through many times why they are expected. Interfaces only report one set of latency data for input and output and that has to apply to all IO ports analog and digital. interfaces will report the latency for their analog IO ports and Pro Tools will correct for this, if you use digital inserts they will have lower latency than reported and therefore be shifted ahead/negative time. Totally expected behavior, and you can correct that in the track comp adjustment setting. H/W inserts using outboard S/PDIF, ADAT, MADI converters can also be ahead/negative time anytime their total conversion delay is slower than the latency reported by the interface.

Now interfaces could, at least in CoreAudio report different latencies for analog and digital IO by using separate streams and reporting stream latencies, but its just not done, and I expect no DAW would pay attention to it. And it would not help incases where outboard digital converters are being used since there is no way for them to report latency data to the driver.

That is the root cause of expected negative offsets, other ones I have seen is users entering incorrect HW latency values... esp not measure those with delay comp *on* since with delay comp on Pro Tools is using the driver reported latencies to adjust HW insert delay in addition to (not instead of) what is entered in the HW insert latency table. I have also seen cases of simple mistakes where folks have entered some but not all of the values there, or where the values may have been deleted, and seen case of suspect corrupt sessions causing problems.

Nobody here can know what your setups look like exactly ...did they involve mixed analog and digital IO, what troubleshooting did you do exactly? The thing is this does works perfectly for many of us across multiple interfaces.

There certainly are technical possibilities that some DAWs and some drivers manage to screw up working together while they work OK with others. Starting with there is some broad developer confusion in basic details of how latency reporting in CoreAudio works, I would hope Lynx and Avid developers are above that, but when I see JUCE the leading plugin toolkit get basic stuff with coreaudio reported driver delays wrong (since corrected) that was just disappointing.

If you are not using LLM you should not be exposed to bug PT-293686. Which leads back to maybe this is specific to Lynx and Pro Tools not working well together. Assuming this is necessarily a Pro Tools bug is not likely to help solve it.

The reasons the other threads stopped as far as I know is nobody made any progress with Avid or Lynx support. Do you have support cases open? Everybody with these issues should have cases open with both companies. Ideally with simple demos sessions showing failure. Get multiple users support cases and start making noise. Complaining without a list of support cases is likely wasting time. Avid support is fairly problematic, you need to spoon feed them and push to get anything useful to happen.

And the other part of this is nobody had produced any measurements or tests that fingered a cause, not that users may be able to, but it may be worth trying. I don't have a Lynx i terfsce, but I have a developer level understanding of how latency data is reported in CoreAudio. One guy offered to work with me to get some numbers but went on vacation and now I got busy and we have not been connecting. You got support cases open with Avid and Lynx? can you run Oblique Audios RTL measurements (https://oblique-audio.com/rtl-utility.php) on your interface with just straight through cable loopbacks. Ideally share the text logs of those not screenshots. Willing to run some test code of mine? but I will be slammed for the next several weeks.

[Guilla]

Originally Posted by Darryl Ramm

Negative delay offsets when working with mixed analog and digital IO on an interface are easy to understand and I and others have gone through many times why they are expected. Interfaces only report one set of latency data for input and output and that has to apply to all IO ports analog and digital. interfaces will report the latency for their analog IO ports and Pro Tools will correct for this, if you use digital inserts they will have lower latency than reported and therefore be shifted ahead/negative time. Totally expected behavior, and you can correct that in the track comp adjustment setting. H/W inserts using outboard S/PDIF, ADAT, MADI converters can also be ahead/negative time anytime their total conversion delay is slower than the latency reported by the interface.

Now interfaces could, at least in CoreAudio report different latencies for analog and digital IO by using separate streams and reporting stream latencies, but its just not done, and I expect no DAW would pay attention to it. And it would not help incases where outboard digital converters are being used since there is no way for them to report latency data to the driver.

That is the root cause of expected negative offsets, other ones I have seen is users entering incorrect HW latency values... esp not measure those with delay comp *on* since with delay comp on Pro Tools is using the driver reported latencies to adjust HW insert delay in addition to (not instead of) what is entered in the HW insert latency table. I have also seen cases of simple mistakes where folks have entered some but not all of the values there, or where the values may have been deleted, and seen case of suspect corrupt sessions causing problems.

Nobody here can know what your setups look like exactly ...did they involve mixed analog and digital IO, what troubleshooting did you do exactly? The thing is this does works perfectly for many of us across multiple interfaces.

There certainly are technical possibilities that some DAWs and some drivers manage to screw up working together while they work OK with others. Starting with there is some broad developer confusion in basic details of how latency reporting in CoreAudio works, I would hope Lynx and Avid developers are above that, but when I see JUCE the leading plugin toolkit get basic stuff with coreaudio reported driver delays wrong (since corrected) that was just disappointing.

If you are not using LLM you should not be exposed to bug PT-293686. Which leads back to maybe this is specific to Lynx and Pro Tools not working well together. Assuming this is necessarily a Pro Tools bug is not likely to help solve it.

The reasons the other threads stopped as far as I know is nobody made any progress with Avid or Lynx support. Do you have support cases open? Everybody with these issues should have cases open with both companies. Ideally with simple demos sessions showing failure. Get multiple users support cases and start making noise. Complaining without a list of support cases is likely wasting time. Avid support is fairly problematic, you need to spoon feed them and push to get anything useful to happen.

And the other part of this is nobody had produced any measurements or tests that fingered a cause, not that users may be able to, but it may be worth trying. I don't have a Lynx i terfsce, but I have a developer level understanding of how latency data is reported in CoreAudio. One guy offered to work with me to get some numbers but went on vacation and now I got busy and we have not been connecting. You got support cases open with Avid and Lynx? can you run Oblique Audios RTL measurements (https://oblique-audio.com/rtl-utility.php) on your interface with just straight through cable loopbacks. Ideally share the text logs of those not screenshots. Willing to run some test code of mine? but I will be slammed for the next several weeks.

Great pieces of knowledge in there!
Thanks for sharing this!!

I can't seem to find a way to put negative value in HW delay compensation, I know there is a way to change the overall delay compensation I think, but would it just screw everything over? Also that might not be a solution if the value keeps on changing.

This thread looks a lot like mine : https://duc.avid.com/showthread.php?t=420254&page=3
I see you interacted and people had similar situation as mine.

I don't have a support ticket open with Avid, I am not on the support plan anymore, last time I tried to open a suppor ticket it was a massive waste of time.

Also bear in mind, the issue is similar with my Arturia interface, and was the same with my ex-interface UAD silverface. So it is not Lynx only. I think this is important to note.

I can do that yes, if it helps to solve this issue once and for all, I am willing to participate as much as I can.

[Dax Productions]

Avid needs to add a ping feature. Full stop.

If so many interfaces are reporting incorrect latency, just add functionality to properly measure it.

[Darryl Ramm]

Originally Posted by Dax Productions

Avid needs to add a ping feature. Full stop.

If so many interfaces are reporting incorrect latency, just add functionality to properly measure it.

Yes. Embarrassing Pro Tools does not have this. And hopefully done well/better than some some if the ping implementations out there that still manage to be slightly confusing.

But it also needs known bugs fixed first.

And to be clear, I am not sure any interfaces are reporting *incorrect* latency.

[Darryl Ramm]

I can't seem to find a way to put negative value in HW delay compensation, I know there is a way to change the overall delay compensation I think, but would it just screw everything over? Also that might not be a solution if the value keeps on changing.

You cannot enter negative values in the HW delay compensation page. That is broken historical Avid design of that page assuming you are compensating only for additional latency in the outboard processing box. Also not supporting samples is brain dead. But as I tried to say, you can compensate for negative offsets by adjusting the track delay compensation offset, the +/- setting you enter in the delay compensation view in the mixer track. Users do this all the time when using digital inserts or analog inserts through converters hanging off digital IO. Lots of discussion in the past on this on DUC from me and bscout.

In mixed analog and digital IO environments the negative offset should be no more than around the DAC+ADC conversion time. So check that makes sense. Huge offsets may be corrupted sessions, very messed up routing, maybe an unknown bug?

I don't have a support ticket open with Avid, I am not on the support plan anymore, last time I tried to open a suppor ticket it was a massive waste of time.

You may be wasting time without opening a case. I know Avid support can be a PITA. They ignored another users brilliant bug discovery and report of a bug and I had to refile and poke them to get PT-293686 opened. And that's just opened not fixed, and no useful status on fix work. I suspect if you want to make any progress you need to pay for a ASC and file a support case, with super clear recipe to reproduce a problem, exact rtl measurements you make, what exact wrong offsets.

Also bear in mind, the issue is similar with my Arturia interface, and was the same with my ex-interface UAD silverface. So it is not Lynx only. I think this is important to note.

OK, I latched onto Lynx because there seems to be more reports there than others. but I am not sure what your issue exactly is, what exact RTL latencies are you measuring (with delay comp on), what exactly are you entering etc. and where is a reproducible demo of the problem. Have you got this all written up somewhere? You say things like you are entering 46.xxms... but these fragments of data only lead to more questions... what outboard box were you using there (maybe it had 46ms latency?) what happens when you use all straight through cables? At what sample rate and IO buffer size, and you are sure that delay comp was enabled. Then can you reproduce in a trivial session with one or two tracks, no sends, no software plugins? (and be careful of not running out of delay comp if you have insane plugins or routing, and be on the lookout for rare plugins that report the wrong latency). Again start if you can by writing up clearly how to reproduce a problem.

But if you are telling me three different brands of interfaces are going to have HW insert latency problems (and its not the known LLM bug) I am going to start to suspect its something you are doing. Either doing "wrong" or some unique setup that is triggering an unknown bug.

The jumping around of values is maybe the most weird thing. Did that happen for all hardware? Are you are sure this is at same sample rate and IO Buffer size? can you give numbers in samples and sample rate? And there really was no way somebody enabled LLM? the numeric values of delays often help point to potential causes, measure to a sample if you can.

Nobody can say doing anything here, sharing example sessions, writing up exactly how to reproduce a problem, testing/measuring stuff, filing support cases etc. will solve any problem. But I would expect doing some or all of those is the minimum to make progress.

[Guilla]

Originally Posted by Darryl Ramm

You cannot enter negative values in the HW delay compensation page. That is broken historical Avid design of that page assuming you are compensating only for additional latency in the outboard processing box. Also not supporting samples is brain dead. But as I tried to say, you can compensate for negative offsets by adjusting the track delay compensation offset, the +/- setting you enter in the delay compensation view in the mixer track. Users do this all the time when using digital inserts or analog inserts through converters hanging off digital IO. Lots of discussion in the past on this on DUC from me and bscout.

In mixed analog and digital IO environments the negative offset should be no more than around the DAC+ADC conversion time. So check that makes sense. Huge offsets may be corrupted sessions, very messed up routing, maybe an unknown bug?



You may be wasting time without opening a case. I know Avid support can be a PITA. They ignored another users brilliant bug discovery and report of a bug and I had to refile and poke them to get PT-293686 opened. And that's just opened not fixed, and no useful status on fix work. I suspect if you want to make any progress you need to pay for a ASC and file a support case, with super clear recipe to reproduce a problem, exact rtl measurements you make, what exact wrong offsets.



OK, I latched onto Lynx because there seems to be more reports there than others. but I am not sure what your issue exactly is, what exact RTL latencies are you measuring (with delay comp on), what exactly are you entering etc. and where is a reproducible demo of the problem. Have you got this all written up somewhere? You say things like you are entering 46.xxms... but these fragments of data only lead to more questions... what outboard box were you using there (maybe it had 46ms latency?) what happens when you use all straight through cables? At what sample rate and IO buffer size, and you are sure that delay comp was enabled. Then can you reproduce in a trivial session with one or two tracks, no sends, no software plugins? (and be careful of not running out of delay comp if you have insane plugins or routing, and be on the lookout for rare plugins that report the wrong latency). Again start if you can by writing up clearly how to reproduce a problem.

But if you are telling me three different brands of interfaces are going to have HW insert latency problems (and its not the known LLM bug) I am going to start to suspect its something you are doing. Either doing "wrong" or some unique setup that is triggering an unknown bug.

The jumping around of values is maybe the most weird thing. Did that happen for all hardware? Are you are sure this is at same sample rate and IO Buffer size? can you give numbers in samples and sample rate? And there really was no way somebody enabled LLM? the numeric values of delays often help point to potential causes, measure to a sample if you can.

Nobody can say doing anything here, sharing example sessions, writing up exactly how to reproduce a problem, testing/measuring stuff, filing support cases etc. will solve any problem. But I would expect doing some or all of those is the minimum to make progress.

Yes the delay are quite low and expected from any A/D converters.

My outboardS are full analog, so technically they should not introduce any additional latency. Actually, they all report the same latency. And exactly same latency as straight through cables.
It is the same whether the sessions has sends or not.

Although what baffles me is that the latency is RARELY the same from session to session, even with sessions sharing the same sample rate.
As we speak, the session I just opened, the latency is 1 sample (super mega low!! That's a first). And yet the one I opened yesterday it was 48 samples late, and the one the day after the outboard was 13 samples ahead. THAT, to me does not make sense. And makes mixing with outboard quite unstable. What if, when I reopen the session another day, the delay changes? That'd be insane.
And all these sessions shares the same buffer size and sample rate.
And no LLM.

The thing is, I'd love to be able to reproduce this, but since all sessions have different delays, it's gonna be very tough.
Maybe if the same day, I create the same session twice from scratch and see if there is a difference, that could help? Eventhough that sounds borderline voodoo to me haha ("Make sure all the right planets are aligned before creating the session...").

But I'd love to get this fixed, as so far, only ProTools had been giving me these headaches.
And regarding paying for support, that's a debate I won't open, but I find it laughable at best (like even Apple don't dare doing this that way). So I won't pay to MAYBE find a solution. Paying to find a solution, maybe if I am desperate (but I won't be I think), but paying for a maybe is a big no for me. And I think it should be for anybody else, but again it's another debate hehe :).

[JFreak]

So long ago, but I remember PT latency compensation had problems after last version without cloud collaboration (12.4) and year.month releases. I'm afraid you will always have random latency errors if you decide to keep using the version you have.