Tracking with Buffersize 32?

[Darryl Ramm]

Ya all talking about hardware inserts or separate track outputs and inputs.

And the fun of doing these measurements is you might find at least two known latency bugs in Pro Tools. I mean why should anybody expect Pro Tools to get basic stuff like time and phase alignment correct.... for fun start by toggling on and off ignore errors and see if that messes up things.

Oh no I posted to the perpetual monitoring latency thread, I'll be trapped here forever...

[685]

Originally Posted by JFreak

it should not if you do not use hardware insert for it, but better play safe if you are measuring.

I'm not sure I understand what you mean by this statement?


And is there anyway possible that Protools would still compensate for the new recording with auto delay comp turned off? Sync up the original and the new with ADC off?

[JFreak]

PT delay compensates hardware insert DA/AD but does not compensate for normal output hardwired to normal input.

[JFreak]

Originally Posted by Darryl Ramm

Oh no I posted to the perpetual monitoring latency thread, I'll be trapped here forever...

Maybe you bite the next reindeer

[685]

Originally Posted by JFreak

PT delay compensates hardware insert DA/AD but does not compensate for normal output hardwired to normal input.

Yes, and with ADC turned off Protools will not/should not compensate for either audio path correct? That's has been my understanding for several years now.

Originally Posted by Darryl Ramm

Ya all talking about hardware inserts or separate track outputs and inputs.

And the fun of doing these measurements is you might find at least two known latency bugs in Pro Tools. I mean why should anybody expect Pro Tools to get basic stuff like time and phase alignment correct.... for fun start by toggling on and off ignore errors and see if that messes up things.

Oh no I posted to the perpetual monitoring latency thread, I'll be trapped here forever...

I've attached a screenshot of the test path. ADC is off and the hardware output and input are connected with analog cables. The two audio files should show some type of latency correct? Then measure the distance in samples and convert that to milliseconds based on the session sample rate.
Playback engine set to 64, cache at 8GB, and no other options checked.

[Darryl Ramm]

Originally Posted by 685

I've attached a screenshot of the test path. ADC is off and the hardware output and input are connected with analog cables. The two audio files should show some type of latency correct? Then measure the distance in samples and convert that to milliseconds based on the session sample rate.
Playback engine set to 64, cache at 8GB, and no other options checked.

Please stop OVER-complicating simple things.

What has ADC got to do with this? ADC compensates for insert latency, the internal reported latency from plugins, and when using hardware inserts the interface output and input latency reported via its driver (for CoreAudio or ASIO interfaces) or seemingly hardcoded into Pro Tools for Digidesign interfaces. That is all it does.

(And because it's a persistent point of confusion: The Setup>IO>Insert page lets you add correction for additional latency introduce by the external H/W insert device. So it can't reduce what Pro Tools thinks the insert latency is if the driver reported latencies are not correct (and they are expected to be wrong if you have mixed digital and analog paths in an interface, like using ADAT mic/line inputs)... to do that you use the +/- track delay compensation. And yes Pro Tools needs to be cleaned up here, including have a ping function like modern DAWs.).

Normal input and output interface latencies are corrected by Pro Tools independent of ADC, again using latency reported via the interface driver (for CoreAudio or ASIO interfaces) or seemingly hardcoded into Pro Tools for Digidesign interfaces. If a DAW did not do this you would have hell of a time getting basic stuff to work.

To me the fastest way of measuring hardware RTL is with a hardware insert with ADC turned off. Take a click track, record it to an audio track, bung a H/W insert on that track and then record that track output to another. Measure the offset in the two audio tracks.

[Darryl Ramm]

Originally Posted by JFreak

Maybe you bite the next reindeer

Ya never told me the girls have antlers.

[LDS]

Originally Posted by 685

Sorry to revamp this but how are you guys actually measuring your native Protools system's RTL(round trip latency) in 2023?
I do feel as if I'm asking a rhetorical question but I'm asking to clarify a few things. With auto delay comp turned off, I normally send the audio out a physical output, re-record it on another input, than measure the space in between the start of each audio file by samples before converting to milliseconds.


.

If you are configuring the offset values in the I/O menu, there is a section in the manual that explains the measurement procedure. IIRC, it has slightly changed in recent releases, but it might just be the wording rather than the procedure itself.

If you are just interested in knowing total system latency, RTL tool by Oblique Audio is great if you have a second system for measurement. For example, Pro Tools DAW RTL = Total RTL - Measurement system RTL. By using a second system, you can stack plugins or change routings or test Avid DSP hardware in Pro Tools and get some very accurate results of how it affects the overall latency. The measurement ‘system’ doesn’t need to be anything fancy. It could just be an extra USB audio interface or the internal sound card running on your Pro Tools machine that gets used exclusively by the RTL tool. It just needs to have stable latency on repeated tests, then you can connect it to any other system to measure its latency.

[Darryl Ramm]

I'm not actually sure what any of this is about. What latency are we trying to measure and why? And what has this got to do with this nonsense thread?

[685]

Originally Posted by Darryl Ramm

Please stop OVER-complicating simple things.

What has ADC got to do with this? ADC compensates for insert latency, the internal reported latency from plugins, and when using hardware inserts the interface output and input latency reported via its driver (for CoreAudio or ASIO interfaces) or seemingly hardcoded into Pro Tools for Digidesign interfaces. That is all it does.

(And because it's a persistent point of confusion: The Setup>IO>Insert page lets you add correction for additional latency introduce by the external H/W insert device. So it can't reduce what Pro Tools thinks the insert latency is if the driver reported latencies are not correct (and they are expected to be wrong if you have mixed digital and analog paths in an interface, like using ADAT mic/line inputs)... to do that you use the +/- track delay compensation. And yes Pro Tools needs to be cleaned up here, including have a ping function like modern DAWs.).

Normal input and output interface latencies are corrected by Pro Tools independent of ADC, again using latency reported via the interface driver (for CoreAudio or ASIO interfaces) or seemingly hardcoded into Pro Tools for Digidesign interfaces. If a DAW did not do this you would have hell of a time getting basic stuff to work.

To me the fastest way of measuring hardware RTL is with a hardware insert with ADC turned off. Take a click track, record it to an audio track, bung a H/W insert on that track and then record that track output to another. Measure the offset in the two audio tracks.

First off
Can you please stop with your consistent internet arrogance! It gets old pretty quickly! lol

I asked these questions in the way I did for a specific reason. I've also done round trip latency measurements many times over the years using a few different ways including the one you mentioned(Take a click track, record it to an audio track.....). I ran the tests recently and a was only getting 1 sample of latency at 48k and thought it was very strange. I could not figure it out and didn't have time in between sessions to re-read through tech docs or search through forums like I wanted to. My gut feeling was that Protools might still be compensating for the I/O recording pass even with auto delay compensation uncheck/turned off. When you mentioned the "ignore errors" feature which I never ever use in Protools I thought it was worth a try. I exactly saw that mentioned in the Youtube video comment a while ago but totally forget about it so thank you.
I turned it on(checked the boxes), ran the RTL test, and got 66 samples of latency which converts to 1.375ms at 48k or 0.69ms at 96k with a hardware buffer setting of 64. Seems better than what the interface manual mentioned but I'll take it. So all and all, I was conducting the tests correctly and now guess I understand why I was only get 1 sample of latency. When I got more time I'll look up more info.



out!