Recording Latency Experiments (with Pictures!)

[clorox]

I wanted to start a thread because I think understanding latency is important, and extremely misunderstood. For example, most users don't understand the difference between monitoring latency (adjustable via buffer size) and recording latency in LE (which is not adjustable at all.)

This experiment deals with recording latency. If you're trying to layer percussion, or layer 5 or 6 guitars, not understanding latency can really make things a nightmare for you.

For the uninitiated, I'm not going to explain the basics (what a sample is, what 44.1 means, etc.). There are plenty of posts and other resources to explain these things.

Screen shots of this experiment:
http://www.the-outside.com/latency1.tiff
http://www.the-outside.com/latency2.tiff

I did some tests on my own, inspired by CCash's excellent latency explanation at http://pages.sbcglobal.net/ccash/latency.htm and Digi's answerbase discussion of this topic at http://answerbase.digidesign.com/detail.cfm?DID=7868 . These should be required reading for any LE owner!

I would love for anyone to do these same 4 tests on different systems (001, 002, 002 rack, mac, pc) and post their findings here for public use. We can call it the "Clorox Test". [img]images/icons/grin.gif[/img]

The new "Click" plugin available in 6.0 makes this experiment easy. Everything below was done using mbox on ibook at 44.1k samples/second. I'm precisely measuring latency through different routes out of/into the mbox 6.0.1 LE system on mac OS 10.2.6. The results SHOULD be the same on any mac/mbox combo, however.

Tracks:
1) Click Plug-in enabled track
2) Recorded bus directly from Track1. Since the plug-in doesn't generate a visible waveform, I had to bounce it to another track.
3) Track 1 sent out S/PDIF channel 01 of mbox and recorded from S/PDIF channel 01 input. Basically, connecting the S/PDIF out directly to S/PDIF in while soloing the Click.
4) Track 1 sent out Analog01 of mbox and recorded frim Input01. Basically, connecting Line01 to Input01 on the mbox while soloing the Click.
5) Track 2 (recorded click from bus) sent out Analog01 of mbox and recorded from Input01. Basically, connecting Line01 to Input01 on the mbox while soloing Track 2 (the recorded click track).

Findings:
Track02 has a latency of 0. I used it as a reference "baseline" with which I compared all other tracks.
-----
Track03 had a latency of exactly 164 samples compared to Track02. This is exactly the number Digidesign said it would be. This number proves that there is latency even if you bypass the A/D and D/A converters.
-----
Track04, the raw click track sent out and in the analog inputs, had a latency of 180 samples. I would expect this to be higher than 164, because of the A/D and D/A conversion. However, this CONTRADICTS what digi and CCash say. It's supposed to be 164, all the time, every time.
-----
Track05, the same as track04 except using the RECORDED click as a source from track02, was identical to Track04 with a latency of 180 samples. This proves that Track02 had no latency , and that you can record from a bus with no latency.

Questions 2 be answered:
1) The 180 number is interesting. It's apparently (and this is just a guess) the product of Processing->D/A->USB->A/D->USB->Processing. How many samples can be attributed to each step?
2) The S/PDIF test removes the converters from that equation: Processing->USB->USB->Processing. This means that D/A + A/D is a mere 16 samples. Is that right?
3) Do plug-ins effect any of these figures, particularly the zero latency bus recording?
4) If you have a Digi001, and record simultaneously to S/PDIF and the Analog inputs, you may have phasing problems due to the slight offset between S/PDIF and Analog tracks. This is only true if my experiment extends to 001. This problem would be the same if you recorded on mbox via S/PDIF and "flew in" analog recorded tracks.

Please share with us what your own results are. Will be performing some more tests on my PC 001 setup shortly.

[espron]

As the 002 offers lower latency than the 001, I really cannot imagine that the 002r will be any different. Where have you heard that the 002r will have higher latency than the 001? BTW the 002r interfaces to the computer by firewire, not usb.


Espen

[clorox]

Originally posted by espron:
As the 002 offers lower latency than the 001, I really cannot imagine that the 002r will be any different. Where have you heard that the 002r will have higher latency than the 001? BTW the 002r interfaces to the computer by firewire, not usb.
Espen

<font size="2" face="Verdana, Arial">The 002 offers a lower buffer size (I think it's 64 samples), which affects monitoring latency, which is COMPLETELY different from recording latency.

As for 002 and 002r's recording latencies, the jury's still out. I read that it was higher, but no one's done the "Clorox Test", which will let us know for sure, and Digi's not documenting it.

Thanks for the Firewire correction. I edited my post to reflect.

If you're confused, I suggest reading the links in the original post. They rock!

[img]images/icons/smile.gif[/img]

[letrev]

Yes, it definitely is important for PTLE users to understand the effects of and how to solve for latency. What really boggles my mind is that digi hasn't yet been able to write any code that automatically compensates for recording latency.

Since they know that there are 164 samples of latency on Mbox, why do we have to manually grab the track and pull it back by 164 samples? It seems so obvious, but I'm sure there must be a good reason...

[clorox]

My personal experiments show that Digi doesn't know for a fact that it's going to be exactly 164 samples all the time.

I think there's a disparity between latency in S/PIF I/O, which I'm measuring at exactly 164, and analog input, which I'm measuring at about 180. Furthermore, what if you're monitering via S/PDIF and playing into the analog jack? Is that 172?

This could, at the very least, cause phasing problems, and I believe is a "known bug".

What I'm more interested in is how the latency compares from system to system. For example, does the 002r have more/less latency than the 001. Might be a compelling reason for people to upgrade or not.

Throughout all this, there is a lot of confusion and misinformation. That's why I'm trying to standardize a way for people to gather facts.

What's your system's "Clorox Test" numbers?

[letrev]

Would it not be possible for the system to self-measure the latency by comparing the start of signal at the front-end with the receipt of the first sample at the back-end of the A/D??

I guess I just don't have the patience or attention span to do all of the testing/measuring. I'd rather the paid engineers do that work for me!

[jnash]

I agree with letrev:

Any easily-predictable amount of recording latency should be compensated for by the software. There should be no need for customers to perform latency experiments to see how far recorded audio is displaced from where it should be--we should be able to trust Digi to get things like this right.

And the idea that Digi is publically recommending that users shift all audio regions by a constant amount to compensate for recording latency strikes me as both laughable and tragic.

Come on, Digi... having PTLE shift those regions automatically has got to be an entirely trivial operation. I appreciate that you're being (somewhat) upfront about the recording latency, but why not recognize it for what it is: a bug... an easily-fixable bug.

And please let me clarify... I'm not trying to rail on Digi here... I don't have an axe to grind... I think you guys are doing a lot of great things, and I rely and depend on your products as a musician and producer. But unless I'm missing something, compensating for a fixed amount of latency is such an easy thing to do, and the results are so significant to the quality of the product, that I honestly can't fathom why it hasn't already been done. And that's without even getting into plug-in latency... OK, I know that some plug-ins have variable amounts of latency, but how hard could it be to compensate for *KNOWN* amounts of plug-in latency at playback time ?

Recording latency strikes me as too big a bug to file away and ignore, especially considering how easy the solution has got to be. And plug-in latency is slightly more complicated, but it's still child's play compared to digital mixing and crossfading, to name just a few of the difficult things that PT already handles well. Even monitoring latency... that's a much harder issue, and PTLE already handles it pretty well, with adjustable buffer sizes and a low-latency mode that disables bussing and plug-ins.

Why not just put the trivial recording latency bug to bed ?

Patch set, anyone ?

James
[email protected]

[clorox]

Originally posted by jnash:
I agree with letrev:

Any easily-predictable amount of recording latency should be compensated for by the software.

<font size="2" face="Verdana, Arial">Everything you said is true, except I don't think Digi can know how much latency is going to be in any given situation. They acknowledge two numbers that I know of: 164 for mbox and 51 for 001.

I just finished testing on my 001. Those two numbers are just the beginning.

Here is the range of my tested combinations, sorted by latency in samples and not including any outboard gear:

0 - recording directly from bus: mbox
7 - recording spdif out to spdif in: 001
51 - recording analog out to analog in: 001
164 - recording spdif out to spdif in: mbox
180 - recording analog out to analog in: mbox

I guess I could isolate different A/D, D/A converters by linking the 001 and mbox, but it's just easier to test each chain before I use it. [img]images/icons/frown.gif[/img]

Imagine the infinite combinations of people using outboard A/D converters, processors, the Digi A/D, D/A, etc.

[CCash]

Well I think it's great that you actually have the motivation to find out and *understand* the answers yourself.

Your mbox numbers surprise me. I don't have an mbox, so I could never test its latency. I assumed that the 164 number was the A/D and D/A round-trip latency (the equivalent of the 51 for the Digi001). It looks like it's not, because...

A S/PDIF digital transfer doesn't have converter latency... because it's not converting A/D or D/A. But you got 164 samples using S/PDIF, which means it's something else, and I'd speculate that it has to be the USB connection. And when you did the analog in and out test you got 180 samples. So maybe the D/A A/D on the mbox is only 16 samples. That seems really low, but it would explain it. Happy testing.

[jnash]

Originally posted by clorox:
<blockquote><font size="1" face="Verdana, Arial">quote:<hr /><font size="2" face="Verdana, Arial">Originally posted by jnash:
I agree with letrev:

Any easily-predictable amount of recording latency should be compensated for by the software.

<font size="2" face="Verdana, Arial">Everything you said is true, except I don't think Digi can know how much latency is going to be in any given situation. <hr /></blockquote><font size="2" face="Verdana, Arial">Well, these are good points: the situation is a bit more complicated than just a constant shift of one single amount. But, then again, it's not THAT complicated...

For starters, the most troublesome kind of recording latency (at least to me, and I'm guessing maybe for most folks ?) is analog out / analog in. That is, if I'm monitoring through the 001's analog mix bus while overdubbing through the 001's analog inputs, I expect the track I'm recording to be put in the right spot... not 51 samples too late. My guess is that fixing that one problem is 1) very easy, and 2) a solution for the majority of recording latency concern out there.

And from there, we get into the digital realm, but a complete solution still doesn't seem so much more complicated:

Digi products don't have that many kinds of inputs and outputs... the 001 has analog ins and outs, ADAT ins and outs, and S/PDIF ins and out. Worst case, that's six latency constants to be concerned with, so while there are an infinite number of ways those ins and outs can be combined (not really, since there are limits on tracks, ins and outs, etc... but there are still a ton of combinations), all the software has to do is keep track of the six ways of getting audio in and out of the device, and apply the appropriate correction for each patch... it's a dizzying task to try to handle yourself, but that's exactly why the computer should do it... it's a fixed, small set of rules that gets applied repetitively for complex scenerios... computers are good at that kind of task.

Then, the other complication clorox proposed is aftermarket digital gear--a good point as well. But, PT could provide an interface for users to input the latency of rogue gear connected to LightPipe, S/PDIF, or whatever.

Or then again... maybe not... if Digi fixed the recording latency for their own product (meaning no latency when there's a direct patch between analog out to analog in, or digital out to digital in--and I don't think I'm being too inflamatory by calling this a bug), then I think they could easily justify ignoring any latency added by other products. Sure, it would be nice if there were automatic compensation for plug-ins, and sure it would be nice if there were a way to tell PT that the device connected to LightPipe has a latency of XXX samples... that would be great!

But, for starters... if Digi would just fix the immediate recording latency associated with analog in/analog out and digital in/digital out... personally, I'd be a happy camper.

And by my estimation, they would have taken latency concerns out of the realm of "bugs" and into the realm of "feature requests."

James
[email protected]