Measuring the latency (experiments)

[jnash]

I'm curious about the monitoring latency and the values in the PTLE manual. The manual gives 2.7 ms with a 128 sample buffer at 48 kHz. That value is exactly 128/48, which seems like a low estimate--if 128 samples are actually buffered, 2.7 ms allows *zero* time for processing those samples, not to mention A/D conversion. And does a 128 sample buffer mean that 128 samples are buffered going in, and going out ? If so, then I'd expect the monitoring latency (time between the moment an analog signal hits an input channel to the time it comes out an analog output) to be at least 256 samples...

Has anyone else tried to measure the latency ? It's a fairly simple experiment that can be done in a number of ways. When I've tried to measure the latency at 48 kHz with a 128 sample buffer, I've gotten 308 samples (6.4 ms). I measured the latency several ways that seemed reasonable to me, and I got the same answer: 308 samples. The simplest way I got that number is to set up one track to record an input source, route that input to a bus, patch the bus output to another analog input on the 001 and record the 2nd input on another track. Then, record something and measure the distance between peaks on the two tracks. It's easiest using a bus, but I get the same 308 sample measurement if I use the main or the headphone output.

Digi--is this what you mean by monitoring latency ? It seems like a reasonable estimate--if the buffer size is 128 samples, the latency should be twice that plus some additional time for processing and routing, but it's not consistent with what's in the manual.

Also, I measured the SP/DIF latency (main mix out to my DAT recorded back in digitally to another channel--muted, of course at around 6 samples. That makes using digital ins and outs on outboard gear relatively painless--anyone know what the latency is on a TDM system ? It can't be much lower...

One final question: what is the recording latency for the 001/LE ? By that, I mean if I overdub to a pre-recorded track (without monitoring through the 001, of course), is there any delay, or when recording a track does PTLE compensate for the time it takes to read existing tracks, mix them, and convert to analog at the main outputs ?

Thanks,
James
[email protected]

[jnash]

Just discovered one other thing--there appears to be no inherent plug-in latency with LE!

If I take a send from one track and record it onto another track, I get no measurable delay on the second track. Then, I can add RTAS plug-ins to the source track, and I still get no delay! I tried the DigiRack compressor, 4-band EQ, even the D-Verb (set to dry), and saw no latency on the 2nd track. The long delay plug-in has a minimum delay time of .04 ms, and that, of course, introduced some delay, but the other Digi plug-ins I tried had no latency, even when I ran five of them in series!

Of course, this is impossible in real-time--if you monitor a live sound source through a host plug-in, it *has* to introduce some latency. But, it looks like LE is doing what the TDM systems still fail to do--it's automatically compensating for plug-in processing time during playback. I'm impressed!

James
[email protected]

[jnash]

Digi, or anyone else, do these delay times make sense to you ?

I'm getting 308 samples for monitoring latency, and I'm not seeing any latency for plugins on playback. On the negative side, 308 samples is more than twice what the manual estimates. On the positive side, I'm very impressed by the plugin compensation (although it seems strange that no one else is talking about it, since it's an improvement over TDM... maybe I measured wrong ?)

And can anyone confirm the recording latency question ? If I record a track in time with playback of existing tracks, does PT automatically shift the new track ahead to compensate for playback latency ? There are a number of possibly separate events--let's say I'm recording along with an existing drum track, and I want a note to coincide with a kick drum hit:

1) the kick drum hit happens (i.e. the playback time moves ahead to where the kick drum hit occurs)
2) the kick drum hit is actually heard through the monitors (after 128+ samples of latency)--I play a new note at exactly the same time (let's assume I'm perfectly in time
3) the note I play is heard through the monitors (after 128+ samples of latency)

Where does PT put the new note, relative to the existing kick drum hit ?

Thanks,
James
[email protected]