Tracking with Buffersize 32?

[685]

Originally Posted by LDS

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.

Thanks sir
The only reason I asked is because I was only getting 1 sample of RTL through the hardware and thought it was strange. No issues on my end but I just needed to understand why. I will look more into it when I free up early next week.

[Darryl Ramm]

Originally Posted by 685

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

Please in future just create you own thread for your own questions. Spamming onto other people really unrelated threads is super annoying for lots of other users here. And in this case you picked a cracker of an unrelated thread. Ok it has the word latency in it... but it's nothing to do with your question, and you don't explain what you are trying to do or why. So just maybe you get the response you deserve.

This stuff has been covered in multiple other threads... that's not a criticism of you, the amount of confusion out there and repeated on DUC means it's impossible to find stuff and the confusion keeps getting repeated. If I can find a thread I'm thinking of I'll link it here, but I can't even find that now.

Originally Posted by 685

I ran the tests recently and a was only getting 1 sample of latency at 48k and thought it was very strange.

Again you mean going out a track output and back in another track input. 1 sample latency is not strange, that's a measurement error it should be 0 samples.

[SNIP] My gut feeling was that Protools might still be compensating for the I/O recording pass even with auto delay compensation uncheck/turned off.

As I said Pro Tools always compensates for physical IO like this. It is not a part of ADC. A super-common point of confusion.

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.

You still seem confused here, again this is confusing to lots of folks, so not a criticism. Enabling ignore errors is introducing a latency error. Turning on ignore errors should not change what you measure... which should be 0 samples. What you are seeing is a bug. It's a bug I've been posting here a lot about because it keeps tripping up users and not many folks seem to know about it, and I'm hoping Avid might do something about it along with the other latency/ADC/HW insert bug(s?) and general need to clean up/improve this stuff (including adding a H/W insert ping capability).

Again the quick way I would measure conversion RTL in Pro Tools is to use an HW insert with ADC turned off. ... that bypasses both ADC and the automatic track input and output latency correction that you otherwise can't bypass.

All the comments LDS made are great. The RTL utility is very handy, doing external measurement of RTL with another interface is great to do. Sometimes doing free acoustic measurements with a mic and understanding all the delay components is useful.

[and related to this my own developer interest is in some area of CoreAudio internals, I have utilities that report on all of a driver's latency metrics (like RTL Utility also does but you have to step it though doing stuff) and other utilities for reporting CoreAudio driver versions for all types of drivers ... frustrating that is not obvious/simple to do. If there are folks interested in similar things I'd love to talk offline]

[audiolex1]

Originally Posted by Darryl Ramm

Mind if I share?

[audiolex1]

Sorry. That one got away from me.

[Darryl Ramm]

Originally Posted by audiolex1

Mind if I share?

The latenty here is awful, it took 6 months for that to come back around ¯\_(ツ)_/¯

[audiolex1]

Originally Posted by Darryl Ramm

The latenty here is awful, it took 6 months for that to come back around ¯\_(ツ)_/¯

I was just observing and didn't mean to make a stink.

[K Roche]

Originally Posted by Darryl Ramm

If you are going to do it, do it well. So as a community service announcement: A friend got me hooked on popcorn popped in Avocado oil with parmesan cheese grated on top. Quality Avocado oil adds a great flavor and has a very high smoke-point.

Sounds great , my mouth watered just reading your post

[K Roche]

Originally Posted by Darryl Ramm

Your glasses must be gen 2

[audiolex1]

Originally Posted by K Roche

Your glasses must be gen 2

Originally Posted by audiolex1

Sorry. That one got away from me.

This was in surround

[JFreak]

Okay, can we get back to the topic?

My stance is that buffersize does not matter until it is too high regarding total latency. What ultimately matters is latency between mic and cans, and buffersize is only one part of it.

Just simply having "superfast" TDM AD/DA conversion is 3.13ms with zero plugins used. Add 256 buffer is extra 2.67ms if you use native plugins. Totaling 5.80ms as a totally normal TDM session of the yesteryear when it was superfast. Using TDM plugins also add to the number but since we are talking about native buffer, let's assume there are none.

I have posted in many threads that earliest digital pianos had a latency of about 10ms from keypress to sound out, but pianists didn't have a problem with it. How much above 10ms is acceptable? That is personal.

But this wanting to track at 32/16/8/4/2/1 buffer beats me. Bragging rights, I say. By definition digital systems always must have at least 1 sample buffer and the lower the buffer the higher the cost. Better stay where it is acceptable.

Ultimately artist decides what is acceptable. I know some who can only monitor with analog signal chain. Vast majority accept the "about 10ms" latency, but some want to take one can off ears. Only few complain and even then I find out I have used a plugin that introduces extra latency and removing that fixes the situation.

But I am biased, I mostly do FOH + monitors on live gig. Maybe the pressure is bigger in studio.