Measuring Latency, Scarlett 6i6, DiGiGrid, etc.

[Amack]

DAW Audio Latency Measurement Procedure

Here’s a simple procedure that should enable the accurate measurement of audio latencies for any DAW System with an audio interface. Pro Tools 12 (PT) with a Windows 8.1 Desktop PC and a Roland Studio Capture (SC) audio interface were used to demonstrate and validate it.

For audio interfaces that have at least 3 audio inputs and two audio outputs (as in this demonstration), only one recording cycle and three loopback cables are required. The upper configuration in the following diagram was used to measure the entire DAW System’s round trip latency (RTL) as well as its RTL compensation error (RTL error). The lower was used to measure the audio interface direct monitoring latency (DML). If only two inputs or cables are available, two recordings will be necessary. The loopback configuration will then have to be adjusted accordingly to use the available output channels.

With PT, “Low Latency Monitoring” has to be turned OFF to connect Track 2 to Output 2. “Delay Compensation (ADC)” can be either ON or OFF because it only affects plugins and inserts – none which are used in this procedure. If they were used, the effectiveness/accuracy of ADC when ON should show up as the RTL Error and the actual delay should show up as RTL. Since apparently there is no way to shut off RTL correction during recording/tracking, it’s not a concern.

Note that although this procedure uses 4+ cycles of a 1 KHz square wave for a test signal, many other options exist like the "Click" used at http://duc.avid.com/showpost.php?p=2269524&postcount=85. Note that if speakers and mics are used for the loopback(s), the sound travel time needs to be compensated for (it's ~ 1000 ft/s).

Page 1 of the attachment provides more detail on the test configuration. Page 2 shows how the SC outputs were configured and Page 3 provides additional SC configuration details. Page 4 shows the results of the demonstration. The 1st track on page 4 shows the playback signal used. Unlike other DAWs, PT does not display the Input and output latencies reported by audio interfaces. However PT’s “System Delay”, without any inserts (as in this demo), does show the reported output latency minus the buffer size after the 1st track is assigned to an output. As shown in the comments field for the 1st track, the output latency was 267 samples (2.78 ms). The 2nd track shows that PT correctly compensated for the round trip latency experienced by the first loop. The 3rd track shows that the system round trip latency (RTL) measured 391 Samples (4.06 ms), which means that the input latency was 124 Samples (1.29 ms). The 4th track shows that the interface’s direct monitoring latency measured 81 Samples (0.84 ms).

Page 5 of the attachment shows that Ableton Live 9 Lite’s display of the interface’s reported input and output latencies matched the delay measurements with 0 “Driver [RTL] Error Compensation”. That error compensation feature, which can be used to compensate for inaccuracies in interface latency reporting (which seems to be quite common), is not available in PT.

Page 6 of the attachment shows the measured and reported RTLs for all available sample rates and buffer settings available for PT and the SC. The shaded cells show the results of Microsoft Excel formulas based on the data manually entered into the un-shaded cells. The last two columns show the differences between the measured and reported values. The measured results were virtually identical to those reported by the SC to Ableton except for the 44.1 kHz sample rates and the 32 sample buffers. In all but the 5 instances indicated by blue text, the RTL compensation error was 0 samples. The 4 lower blue ones had a +1 sample and the upper had a -1 sample error. The SC’s direct monitor latency measured 81 samples in all cases.

Pages 7 and 8 contain a copy of this write-up.

[Amack]

propower,

Maybe, I'll have to give that some thought, thanks!

I figured out a way to measure interface direct monitoring latency without a scope and started a new thread to show how to do it in addition to the RTL and RTL compensation error measurements addressed in this post. (http://duc.avid.com/showthread.php?p...21#post2268821) I also added additional information that might help more people understand how and why the procedures documented in both threads work. I'd greatly appreciate it if you'd look it over to see if I made any typos, other errors, or omitted something that might help folks understand it.

Thanks Again,

Amack

Originally Posted by propower

For an HDX system the minimum achievable latency at 96kHz is 0.7ms as published by AVID. If one only uses AAX-DSP plugins (and for now lets assume you pick the ones that don;t add more than a few samples of delay) this 0.7ms is valid for however many tracks you can support (64 per HDX card up to I am not sure how many cards) and however many of these AAX-DSP plugins you can instantiate on your HDX cards. There is no relevance for the Audio buffer in this case as it only applies to AAX-Native plugins. Once you use those the HDX platform is the same as Native.

With HDX and AAX-DSP plugins only the Latency of your system is only affected by the sample rate chosen. The computer actually matters little in this case since all the hard work is done on cards. The Buffer is of no importance either unless you use Native plugins.

Make sense?

[propower]

Originally Posted by Amack

propower,

Maybe, I'll have to give that some thought, thanks!

I figured out a way to measure interface direct monitoring latency without a scope and started a new thread to show how to do it in addition to the RTL and RTL compensation error measurements addressed in this post. (http://duc.avid.com/showthread.php?p...21#post2268821) I also added additional information that might help more people understand how and why the procedure documented in both threads work. I'd greatly appreciate it if you'd look it over to see if I made any typos, other errors, or omitted something that might help folks understand it.

Thanks Again,

Amack

I admire the time and effort you have put into this. WRT the naming I would call "RTL error" something like "Loopback error" or "Interface loopback error" since there is no error in RTL only in where the DAW puts incoming audio - it either puts it in the right place or there is an "error".

A quick glance at the direct monitoring latency test looks like it might work. The DAW compensation is cancelled out as in the first test. I will run it tomorrow to see if it agrees with scope and Function Generator.

[Amack]

Fixed it - thanks!

Originally Posted by propower

I admire the time and effort you have put into this. WRT the naming I would call "RTL error" something like "Loopback error" or "Interface loopback error" since there is no error in RTL only in where the DAW puts incoming audio - it either puts it in the right place or there is an "error".

A quick glance at the direct monitoring latency test looks like it might work. The DAW compensation is cancelled out as in the first test. I will run it tomorrow to see if it agrees with scope and Function Generator.

[Amack]

HDX apparently is supposed to work with other DAWs, at least for I/O (http://akmedia.digidesign.com/suppor...uide_75269.pdf). Are you saying that it really doesn't, or that just its plugins/effects don't?

Originally Posted by mesaone

HDX has DSP that only works with Pro Tools. You're driving with your foot on the brake if you buy HDX and *don't* use Pro Tools.

I've noticed you tend to make assertions, then follow them up with "but I don't really know". If you don't know, why are you making such assertions?

HDX isn't for everyone. It's certainly overpowered for what I do at home, but it's a good fit for the 72-channel boards I sometimes work with in the studio. You should keep in mind that different situations (home studio vs studio vs post-production dub stage, etc) have different requirements.

[propower]

Originally Posted by Amack

HDX apparently is supposed to work with other DAWs, at least for I/O (http://akmedia.digidesign.com/suppor...uide_75269.pdf). Are you saying that it really doesn't, or that just its plugins/effects don't?

When you say HDX you mean HDX PCIe Cards. These cards only work with PTHD. There are a few alternate Interfaces that can plug into these cards (Like Aurora for example) using a DgiLink or mini DigiLink connector but that's it. If you think otherwise quote the page you think says this and folks here can clear this up.

[Amack]

propower,

At 96 kHz, your native HD IO and Omni direct monitoring measurements (LLMs) were 0.47 ms. There is apparently 2 buffers in series for the RTL measurements. With 64 bit buffers, that adds another 2*64/96 ms = 1.33 ms of latency for a total RTL of 0.47 + 1.33 ms = 1.8 ms (you measured 1.78 ms).

From what you said about HDX (which explains a lot!), it sounds like that 0.7 ms “Analog to Analog Throughput Latency” is actually the latency through the HD interface (0.47 ms) + the added HDX latency - which apparently is 0.7 ms – 0.47 ms = 0.23 ms.

The PT/HDX overall system RTL (from PT track to PT track) will add additional latency because of the 2 64 bit buffers likely required. So, the actual PT/HDX RTL is probably 0.7 + 2*64/96 ms = 2.03 ms.

Make sense? It sure would be nice if someone would measure it – it’s really easy! (http://duc.avid.com/showthread.php?p...21#post2268821)

Amack

Originally Posted by propower

For an HDX system the minimum achievable latency at 96kHz is 0.7ms as published by AVID. If one only uses AAX-DSP plugins (and for now lets assume you pick the ones that don;t add more than a few samples of delay) this 0.7ms is valid for however many tracks you can support (64 per HDX card up to I am not sure how many cards) and however many of these AAX-DSP plugins you can instantiate on your HDX cards. There is no relevance for the Audio buffer in this case as it only applies to AAX-Native plugins. Once you use those the HDX platform is the same as Native.

With HDX and AAX-DSP plugins only the Latency of your system is only affected by the sample rate chosen. The computer actually matters little in this case since all the hard work is done on cards. The Buffer is of no importance either unless you use Native plugins.

Make sense?

[Amack]

Sorry for the confusion - I was addressing mesaone's comment suggesting that HDX systems with AVID HD interfaces couldn't be used with DAWs other than PTHD. (That's covered near the end of the linked pdf.)

Originally Posted by propower

When you say HDX you mean HDX PCIe Cards. These cards only work with PTHD. There are a few alternate Interfaces that can plug into these cards (Like Aurora for example) using a DgiLink or mini DigiLink connector but that's it. If you think otherwise quote the page you think says this and folks here can clear this up.

[mesaone]

Originally Posted by Amack

I was addressing mesaone's comment suggesting that HDX systems with AVID HD interfaces couldn't be used with DAWs other than PTHD. (That's covered near the end of the linked pdf.)

I never suggested that. I did, however, point out that the DSP offered by HDX only works with Pro Tools (AAX-DSP plug-ins).

Here's what I wrote, bolded text to emphasize what you skipped over.

Originally Posted by mesaone

HDX has DSP that only works with Pro Tools.

[propower]

Originally Posted by Amack

propower,

At 96 kHz, your native HD IO and Omni direct monitoring measurements (LLMs) were 0.47 ms. There is apparently 2 buffers in series for the RTL measurements. With 64 bit buffers, that adds another 2*64/96 ms = 1.33 ms of latency for a total RTL of 0.47 + 1.33 ms = 1.8 ms (you measured 1.78 ms).

The OMNI and HD I/O are both HD I/Os that can be used with HD Native as well. They are NOT Native I/O's. The LLM path is A/D -->dedicated FPGA --> D/A. No buffers in series - no DAW (except the DAW actually controls the simple gain function of the FPGA).

Originally Posted by Amack

From what you said about HDX (which explains a lot!), it sounds like that 0.7 ms “Analog to Analog Throughput Latency” is actually the latency through the HD interface (0.47 ms) + the added HDX latency - which apparently is 0.7 ms – 0.47 ms = 0.23 ms.

Yes! Using only AAX-DSP plugins this is the RTL (0.7) and DSP processing time (0.23). Nothing more.

Originally Posted by Amack

The PT/HDX overall system RTL (from PT track to PT track) will add additional latency because of the 2 64 bit buffers likely required. So, the actual PT/HDX RTL is probably 0.7 + 2*64/96 ms = 2.03 ms.

Make sense? It sure would be nice if someone would measure it – it’s really easy! (http://duc.avid.com/showthread.php?p...21#post2268821) Amack

No - this part is all your conjecture - and it is wrong. With ONLY AAX-DSP plugins you already have the right answer above (assuming the AAX-DSP plugins don;t add latency - some do). HDX does all the processing for AAX-DSP plugins on the cards (in record and playback) - that's the point of the system. This second part is not true. IF you add a Native plugin to an HDX system THEN you will have the DAW buffer times 2 to the latency (and the DAW buffer for HDX is minimum 64/128 96k/44.1K when using HDX cards.