|
Avid Pro Audio CommunityHow to Join & Post • Community Terms of Use • Help Us Help YouKnowledge Base Search • Community Search • Learn & Support |
#1
|
|||
|
|||
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. Last edited by Amack; 06-26-2015 at 01:10 PM. Reason: Update link |
#2
|
|||
|
|||
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. |
#3
|
|||
|
|||
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:
|
#4
|
|||
|
|||
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 |
#5
|
|||
|
|||
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:
|
#6
|
|||
|
|||
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 |
#7
|
|||
|
|||
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:
|
#8
|
|||
|
|||
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 |
#9
|
|||
|
|||
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:
|
#10
|
||||
|
||||
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |