Measuring Latency, Scarlett 6i6, DiGiGrid, etc.

[Amack]

guitardom,

Sorry about my last post, the other guys responded while I was writing it. You’re right about some ASIO interfaces incorrectly reporting input and output latencies though. Although it’s admittedly a small sample size, I think I’ve detected a pattern in mine that can predict if they do or not. Unlike those devices that do report correctly (Studio Capture – always and Scarlett 6i6 Beta - sometimes), those that don’t all show “System Delays” that don’t vary with “H/W Buffer” size variations. That includes ASIO4ALL, Echo AUDIOFIRE4, Fast Track Duo, and Eleven Rack. I wouldn’t count on that though; especially since it’s probably easier to use the posted approach to find out for sure (as well as help ensure that everything is setup correctly and performing as expected before recording/tracking sessions)!

Amack

Originally Posted by guitardom

Different builds it has been terribly off. Assuming the compensation on everything is not perfect in the first trip, results will be off. If the 3rd parties Asio/Core Audio driver reports its latency to PT wrong, the results are off. There is a lot of variables and spots for failure.

[guitardom]

Originally Posted by NewdestinyX

I think it's a 'little more' than mental gymnastics.. From my perspective - I'd want to see this 'double loop' data from several interfaces mostly for Native systems I was considering for clients I'm consulting with about home rigs - where they'd want to know whether they need a mixing board to monitor recorded tracks thru for lowest-latency-possible monitoring on record passes.

I just 'barely' get away with the Presonus FireStudio 2626 with clients on remotes.. when we're cutting overdubs - piano, vocals.. because even with my buffer ramped down to 256 (get pops and cliks if I go any lower than that and buffer underrun error messages that stop transport) - the vocalists say they notice some slight doubling. Not enough for them to throw me out as a rank amateur.. LOL!.. But when I was considering a native solution - Like I think Amack is - for onsite recording.. I'd like to purchase an ASIO interface with the MINIMAL hardware latency possible from real world testing..

So his test is indeed worth it.. In fact I'm gonna do it with my Firestudio2626 too and post results here..

Dude, 256!! That has to be terrible. I won't even run that high on my HDN tracking or in the past with any of my older systems. Even my portable system has to be 64 capable. I would spend the time to track down what the issue is with your computer why you can't go lower. The interface A/D D/A is not the problem here.

[Amack]

That sounds like clear thinking to me! I, and likely many others, would like to see real RTL numbers for the various types of interfaces and DAWs out there. It seems to me that a separate DUC category/folder for that information would be quite useful (although AVID likely won't want those numbers advertised so that's not going to happen!) Also, the numbers shouldn't vary much/any with different DAWs.

But, at least if you stick with Windows, it's PT that's likely limiting the overall DAW's performance/latency, not a modern 3rd party interface that's "stable" with PT. See http://duc.avid.com/showthread.php?p...=1#post2264405 for additional information.

Thanks Again for Helping Out!!

Amack

Originally Posted by NewdestinyX

I think it's a 'little more' than mental gymnastics.. From my perspective - I'd want to see this 'double loop' data from several interfaces mostly for Native systems I was considering for clients I'm consulting with about home rigs - where they'd want to know whether they need a mixing board to monitor recorded tracks thru for lowest-latency-possible monitoring on record passes.

I just 'barely' get away with the Presonus FireStudio 2626 with clients on remotes.. when we're cutting overdubs - piano, vocals.. because even with my buffer ramped down to 256 (get pops and cliks if I go any lower than that and buffer underrun error messages that stop transport) - the vocalists say they notice some slight doubling. Not enough for them to throw me out as a rank amateur.. LOL!.. But when I was considering a native solution - Like I think Amack is - for onsite recording.. I'd like to purchase an ASIO interface with the MINIMAL hardware latency possible from real world testing..

So his test is indeed worth it.. In fact I'm gonna do it with my Firestudio2626 too and post results here..

[guitardom]

Originally Posted by Amack

guitardom,

Sorry about my last post, the other guys responded while I was writing it. You’re right about some ASIO interfaces incorrectly reporting input and output latencies though. Although it’s admittedly a small sample size, I think I’ve detected a pattern in mine that can predict if they do or not. Unlike those devices that do report correctly (Studio Capture – always and Scarlett 6i6 Beta - sometimes), those that don’t all show “System Delays” minus “H/W Buffer” sizes that don’t vary with “H/W Buffer” size variations. That includes ASIO4ALL, Echo AUDIOFIRE4, Fast Track Duo, and Eleven Rack. I wouldn’t count on that though; especially since it’s probably easier to use the posted approach to find out for sure (as well as help ensure that everything is setup correctly and performing as expected before recording/tracking sessions)!

Amack

It's not easier to use your approach because it is showing nothing really useful. Everything we need to see is the compensation with 1 loop. It's that simple. It's what we have always used to verify compensation is working correctly as it represents how we work.

This second loop is not representative of any sort workflow or any situation we have to think about. You can think it represents what you want, fact is that it is not representative of anything really useful.

If everything is compensated for on your interface on the first loop, where is the problem and what is not right even though the Second loop may say 213 samples???

[propower]

Originally Posted by guitardom

This second loop is not representative of any sort workflow or any situation we have to think about. You can think it represents what you want, fact is that it is not representative of anything really useful.

If everything is compensated for on your interface on the first loop, where is the problem and what is not right even though the Second loop may say 213 samples???

The difference between the first loop and the second loops is exactly the latency you hear when (for example) singing into a mic (+ the small amount due to your distance from the mic). For people recording acoustic instruments and voice this is very valuable information (IMO of course). How can this not be important to you?

It is actually the first loop (which should be zero) that is unimportant - unless its not zero - in which case it is also very important and needs to be compensated for either via a DAW setting or in ProTools by using DDMF Metaplugin. If you don;t your recorded tracks are out of sync with what you played them to. How is any of this not important or at the very least - valuable?

[guitardom]

Originally Posted by Amack

That sounds like clear thinking to me! I, and likely many others, would like to see real RTL numbers for the various types of interfaces and DAWs out there. It seems to me that a separate DUC category/folder for that information would be quite useful (although AVID likely won't want those numbers advertised so that's not going to happen!) Also, the numbers shouldn't vary much/any with different DAWs.

But, at least if you stick with Windows, it's PT that's likely limiting the overall DAW's performance/latency, not a modern 3rd party interface that's "stable" with PT. See http://duc.avid.com/showthread.php?p...=1#post2264405 for additional information.

Thanks Again for Helping Out!!

Amack

Why would Avid have issues with these numbers?? They are representative of the 3rd party developers drivers and would be the same on any Daw. Don't you think between the dozens of interface developers, we would be told if Pro Tools does not perform as well as other daws with Asio/Core Audio drivers??? Any interface will have its latency numbers listed by the developer. There is not a separate PT section for these. Not sure where you keep coming up with these conclusions???

[Amack]

Use one loop then and save the expense of the 2nd cable! But, the 2nd loop doubles the distortion produced by the interface and thereby makes it more visible (even more would be even better depending on how much you care or want to know). I used 4 on my Studio Capture

Originally Posted by guitardom

It's not easier to use your approach because it is showing nothing really useful. Everything we need to see is the compensation with 1 loop. It's that simple. It's what we have always used to verify compensation is working correctly as it represents how we work.

This second loop is not representative of any sort workflow or any situation we have to think about. You can think it represents what you want, fact is that it is not representative of anything really useful.

If everything is compensated for on your interface on the first loop, where is the problem and what is not right even though the Second loop may say 213 samples???

[guitardom]

Originally Posted by Amack

Use one loop then and save the expense of the 2nd cable! But, the 2nd loop doubles the distortion produced by the interface and thereby makes it more visible (even more would be even better depending on how much you care or want to know). I used 4 on my Studio Capture

......I don't even know what to say at this point..... You are so confused. I have hundreds if not more cables and a bunch of different interfaces. That is not the issue. What you are seeing, why, and where to look is the issue.

You obviously need to answer this question and think about it.
What does it mean if the first loop shows everything is correctly compensated for and the second loop shows its off?

[Amack]

Additional signal (sound) distortion. How can it be "off" if PT doesn't screw up?

Originally Posted by guitardom

......I don't even know what to say at this point..... You are so confused. I have hundreds if not more cables and a bunch of different interfaces. That is not the issue. What you are seeing, why, and where to look is the issue.

You obviously need to answer this question and think about it.
What does it mean if the first loop shows everything is correctly compensated for and the second loop shows its off?

[mesaone]

Originally Posted by propower

The difference between the first loop and the second loops is exactly the latency you hear when (for example) singing into a mic (+ the small amount due to your distance from the mic). For people recording acoustic instruments and voice this is very valuable information (IMO of course). How can this not be important to you?

As I had pointed out when initially questioning the utility of a second loopback, using live input monitoring addresses this. Same for monitoring in the analog domain pre-interface. And using the RTL utility I provided a link to eliminates all confusion about latency compensation, if the goal is to measure everything without intervention.