Avid Pro Audio Community

Avid Pro Audio Community

How to Join & Post  •  Community Terms of Use  •  Help Us Help You

Knowledge Base Search  •  Community Search  •  Learn & Support


Avid Home Page

Go Back   Avid Pro Audio Community > General Discussion & Off Topic > General Discussion

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 06-03-2015, 05:06 PM
Amack Amack is offline
Member
 
Join Date: Apr 2015
Location: USA
Posts: 846
Default Measuring Latency, Scarlett 6i6, DiGiGrid, etc.

June 16, 2015 - Important Update!

I've updated this procedure to include an audio interface direct monitoring latency measurement, and provided measurement data for the interface that I used to validate the process and its accuracy. I also tried to explain the approach sufficiently that everyone that wishes to can understand and use it. If you have questions or comments, please don't hesitate to ask. (I apologize for my "Tech talk" - too many years in tech I guess.) If you do make some measurements (I hope you do - its quite easy), I and likely many others would really appreciate it if you would share the results! The new procedure is at http://duc.avid.com/showthread.php?p...21#post2268821

Amack



The attachments show the results that I obtained for latency tests/measurements with my Focusrite Scarlett 6i6. Since Focusrite is trying to modify their drivers to work properly with Pro Tools (PT), I used their latest (beta) drivers http://beta.focusrite.com/releases/scarlett_mixcontrol/ for these tests. Standard (non-HD) Pro Tools 12 was used with Windows 8.1.

With the current released version of the Scarlett ASIO driver/Control Panel (Scarlett Mix Control 1.8.128.0) buffer sizes need to be entered via Mix Control before PT starts/restarts. PT should then try to calculate an appropriate approximate buffer size when it starts – and it doesn’t do it very well or reliably! That Scarlett driver does not accept/reflect buffer size changes entered from PT. Using the mesaone/Sweetwater approach that attempts to do so (http://duc.avid.com/showpost.php?p=2260982&postcount=26) will likely cause PT to use a size that’s different from that used by the Scarlett driver - resulting in erroneous latency compensation. For example a Scarlett 1ms buffer size with a 96 kHz sample rate session equates to 96 samples. If anything different that 128 samples is selected as PT’s “H/W Buffer Size” (its closest option) significant errors in latency compensation will occur.

One of the Beta additions appears to be an attempt to make it possible to set the buffer sizes properly from PT. The first page of the attachments shows the newly added device control interface. This appears to be a good PT workaround and enables good (within ~ 1ms) loop-back latency compensation by Pro Tools 12. But, unfortunately, I think it has a long way to go before it will be ready for release.

As the attachments show, I did testing at 48k and 96k Samples/second with the default buffer size of 256 Samples. I did however change the USB Performance Mode to “High” from the default “Safe”. I tried “Safe” too - it adds 4.7 ms to both ASIO latencies, but didn’t really seem to improve reliability/stability. Note that operating with a 96 kHz sample rate causes far less distortion than does 48 kHz.

The basic test setup consisted of connecting the 6i6 as follows: The test signal imported into Track 1 was played on Output 1. Output 1 was externally connected to Input 1 for recording on Track 2. Track 2 was “monitored” on Output 2. Output 2 was externally connected to Input 2 and recorded on Track 3. (It’s important to have the “Low Latency Monitoring” “Option” off, “Delay Compensation” doesn’t matter).

I attempted to use the track labels and comments in the attachments to explain the test configuration and results adequately. I’m kind-of new to this stuff and its terminology so please let me know if there is something that requires clarification.
Attached Files
File Type: pdf Beta 6i6 48 kHz Latency_Part1.pdf (473.1 KB, 0 views)
File Type: pdf Beta 6i6 48 kHz Latency_Part2.pdf (323.9 KB, 0 views)
File Type: pdf Beta 6i6 96 kHz Latency_Part1.pdf (428.9 KB, 0 views)
File Type: pdf Beta 6i6 96 kHz Latency_Part2.pdf (407.5 KB, 0 views)

Last edited by Amack; 06-26-2015 at 01:10 PM. Reason: Update link
Reply With Quote
  #2  
Old 06-03-2015, 05:42 PM
mesaone mesaone is offline
Member
 
Join Date: Oct 2010
Location: USA
Posts: 5,254
Default

Why are you running cascaded loopbacks to measure latency (output 1 to input 1, track receiving on input 1 feeding output 2, recorded back in through input 2 onto a third track)?

That makes no sense. That's double-round-trip, and there's no indication of why you disabled Low Latency Monitoring - which would certainly affect the return time, doubly so since you're returning twice in series.

I really don't understand what you're testing for, and how this methodology applies. From what I see, you're getting good results on the single loopback, and you're only encountering a sizeable latency when looping back twice.

Edit: you realize this is good news, right? From a latency standpoint, the focusrite's beta ASIO driver appears to work quite well. Your second loopback is unnecessary and not representative of any real-world use I can think of.
__________________
Pro Tools HD 12.4, Pro Tools "Vanilla" 12.4, Artist Transport, 2x Artist Mix
Studio Blue: RME UCX, Win7 Pro, i7 960, 16GB || Studio Green: RME Babyface, Win10, i7 7700HQ, 16GB

Last edited by mesaone; 06-03-2015 at 05:54 PM.
Reply With Quote
  #3  
Old 06-03-2015, 06:41 PM
Amack Amack is offline
Member
 
Join Date: Apr 2015
Location: USA
Posts: 846
Default

Since the first round trip should be (and is approximately for this interface) latency compensated, the second round trip is necessary to measure the output to input latency. Turning off low latency monitoring is necessary to enable output for that second round trip.

Quote:
Originally Posted by mesaone View Post
Why are you running cascaded loopbacks to measure latency (output 1 to input 1, track receiving on input 1 feeding output 2, recorded back in through input 2 onto a third track)?

That makes no sense. That's double-round-trip, and there's no indication of why you disabled Low Latency Monitoring - which would certainly affect the return time, doubly so since you're returning twice in series.

I really don't understand what you're testing for, and how this methodology applies. From what I see, you're getting good results on the single loopback, and you're only encountering a sizeable latency when looping back twice.
Reply With Quote
  #4  
Old 06-03-2015, 08:07 PM
mesaone mesaone is offline
Member
 
Join Date: Oct 2010
Location: USA
Posts: 5,254
Default

So your goal is to defeat the input buffer latency compensation in an attempt to show... That there is latency in a system with no input buffer latency compensation?

The compensation doesn't account for output buffers, so what you see with a single loopback is what you get with a standard recording workflow.

Again, I don't see the practical implications of this second loopback. Why not use something like Audacity (which has no such compensation) with a single loopback?
__________________
Pro Tools HD 12.4, Pro Tools "Vanilla" 12.4, Artist Transport, 2x Artist Mix
Studio Blue: RME UCX, Win7 Pro, i7 960, 16GB || Studio Green: RME Babyface, Win10, i7 7700HQ, 16GB
Reply With Quote
  #5  
Old 06-03-2015, 09:03 PM
Amack Amack is offline
Member
 
Join Date: Apr 2015
Location: USA
Posts: 846
Default

I tried Audacity, but I couldn't figure out what it's latency was (it seemed pretty high). As you can see from the info provided, the first loop's latency is approximately (due to PT's approximation of the 6i6 buffer size) properly compensated. Since the second loop is based on the return from the first, the difference between it and the first is the net loop-back latency. (I even used 4 loops on my Studio Capture to verify that there wasn't something that I had overlooked - there wasn't.) Also, the sum of the individually reported input and output device latencies shown by the new Beta driver (as well as other DAWs) was quite accurate in predicting the net loop-back latency. Try it, it's not that difficult! I (and likely others) are curious to see how fast your RME, HDX. and HD devices really are!

Quote:
Originally Posted by mesaone View Post
So your goal is to defeat the input buffer latency compensation in an attempt to show... That there is latency in a system with no input buffer latency compensation?

The compensation doesn't account for output buffers, so what you see with a single loopback is what you get with a standard recording workflow.

Again, I don't see the practical implications of this second loopback. Why not use something like Audacity (which has no such compensation) with a single loopback?
Reply With Quote
  #6  
Old 06-03-2015, 09:14 PM
guitardom guitardom is offline
Member
 
Join Date: May 2004
Location: New Mexico
Posts: 6,807
Default

The second loop back is not necessary and is not indicative of any actual recording procedure. a source signal (recorded click audio) set to Output 1 looped to Input 2 is all you need for any test.

To loop Output 2 to another input is doubling the round trip numbers and not anything you would do in real life. Makes no sense.

Some of us had been dealing with this for 10 or more years until Avid finally give native users compensation. Then we also had issues with some plugins not reporting its latency properly. It used to be a nightmare for native users. There are countless tests posted on here through the years by me and others that are all but useless now. But the procedure is well established.
__________________

pro-tools-pc.com


TRASHER Pro Tools Utility(updated 3-6-18)

HD Native, Avid 16x16, Eleven Rack, Focusrite Clarett 8preX, UA Quad Apollo TB.

Intel I7 9900k
Win 10
Reply With Quote
  #7  
Old 06-04-2015, 09:09 AM
Amack Amack is offline
Member
 
Join Date: Apr 2015
Location: USA
Posts: 846
Default

Would you please provide a link that explains the process and shows the results (of another usable approach)? I was unable to find one.

Quote:
Originally Posted by guitardom View Post
The second loop back is not necessary and is not indicative of any actual recording procedure. a source signal (recorded click audio) set to Output 1 looped to Input 2 is all you need for any test.

To loop Output 2 to another input is doubling the round trip numbers and not anything you would do in real life. Makes no sense.

Some of us had been dealing with this for 10 or more years until Avid finally give native users compensation. Then we also had issues with some plugins not reporting its latency properly. It used to be a nightmare for native users. There are countless tests posted on here through the years by me and others that are all but useless now. But the procedure is well established.
Reply With Quote
  #8  
Old 06-04-2015, 09:55 AM
mesaone mesaone is offline
Member
 
Join Date: Oct 2010
Location: USA
Posts: 5,254
Default

Guitardom gave a concise description of the method - "a source signal (recorded click audio) set to Output 1 looped to Input 2 is all you need for any test."

Looks like the FAQs at DAWbench.com are down, so I can't link you to them. Post 3 of this page explains it. You've already done it, you just added an additional loopback that is not necessary.

You can also use something called RTL Utility, which was designed for these tests. But it will not give you an accurate picture of how Pro Tools will respond, since it lacks the compensation that PT has. So while it will give you "scientific" results, these results don't translate to how your Pro Tools system will behave in real-world recording situations. http://www.oblique-audio.com/free/rtlutility
__________________
Pro Tools HD 12.4, Pro Tools "Vanilla" 12.4, Artist Transport, 2x Artist Mix
Studio Blue: RME UCX, Win7 Pro, i7 960, 16GB || Studio Green: RME Babyface, Win10, i7 7700HQ, 16GB
Reply With Quote
  #9  
Old 06-04-2015, 11:31 AM
Amack Amack is offline
Member
 
Join Date: Apr 2015
Location: USA
Posts: 846
Default

With PT, how does a single loop tell you anything other than how well latency compensation worked? If there was a way to turn it off (is there?) - one loop would suffice. If PT would tell you what values it's using for input and output latency for the compensation (like other DAWs), one loop would suffice (can/does it?). As far as I know the only relevant info provided by PT in that regard is the "System Delay" which is (for this type of session) equal to the output latency provided by the interface's driver minus PT's "H/W Buffer Size".

Thanks for the link to the RTL utility but, after reading the documentation, I decided to stick with the extra loop. To me it seems a lot simpler, less prone to error, and more accurate (1 sample resolution). It also provides info on how much distortion the interfaces cause.

Quote:
Originally Posted by mesaone View Post
Guitardom gave a concise description of the method - "a source signal (recorded click audio) set to Output 1 looped to Input 2 is all you need for any test."

Looks like the FAQs at DAWbench.com are down, so I can't link you to them. Post 3 of this page explains it. You've already done it, you just added an additional loopback that is not necessary.

You can also use something called RTL Utility, which was designed for these tests. But it will not give you an accurate picture of how Pro Tools will respond, since it lacks the compensation that PT has. So while it will give you "scientific" results, these results don't translate to how your Pro Tools system will behave in real-world recording situations. http://www.oblique-audio.com/free/rtlutility
Reply With Quote
  #10  
Old 06-04-2015, 11:35 AM
YYR123's Avatar
YYR123 YYR123 is offline
Member
 
Join Date: Dec 2010
Location: Austin TX
Posts: 13,737
Default

iirc alt click on the delay compensation value and that disables it for that track specifically
__________________
Daniel
HDX - PT12.5.1 - HD I/O 16x8x8
Win10-Pro (v1709)- 6 Core i7-6850k - ASUS X99 Deluxe ii
D-Command Main Unit - 'Ole Blue


http://www.sknoteaudio.com/ plugins rock and are affordable.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
DigiGrid IOS 8IO+ DSP simon.a.billington AAX Plug-ins 0 12-04-2014 07:10 PM
Measuring Analog Distortion? SuperReverb Pro Tools TDM Systems (Mac) 2 10-18-2010 07:02 AM
Correctly measuring input db PTGuy Pro Tools TDM Systems (Mac) 4 05-12-2006 12:36 AM
Measuring Midi Latency JPS 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Win) 15 07-01-2002 10:24 PM
Measuring the latency (experiments) jnash 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 2 04-16-2000 10:15 PM


All times are GMT -7. The time now is 10:04 PM.


Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited. Forum Hosted By: URLJet.com