HDX tracks record 21 samples late

[YYR123]

Silly question but is

100 samples 1 second or 0.1 seconds?

[propower]

20 samples at 96kHz is

20samples/96000samples/second = 0.000208seconds = 0.208msec (corrected 2 posts down

AVID does not publish the A/D and D/A delay times but I have measured the AVID I/Os with HD Native in Low Latency mode which is as close to the A/D + D/A time as we can know. It is 0.47ms at 96kHz and 1.9ms at 44.1kHz. I do not know what "throughput" time is. What the OP did do is what I call loopback testing. Take a signal in your DAW - send it out an output - patch that into another input and record the result. Any delay you see between the source signal and the recorded one is an error (in my book). It mimics a musician getting a headphone feed and playing exactly in time. It is the simplest of all tasks and the most basic one the DAW needs to do.

So at 44.1kHz the A/D plus D/A time is ~1.9ms. Assuming A/D and D/A are equal - now we are 0.95ms of delay.

So is almost a millisecond of any concern? What about 2 or 5 after a bunch of passes.

Is there yet a second HDX owner that can even verify this is how it works? HDN does not work this way.

[Drew Mazurek]

Originally Posted by propower

What about 2 or 5 after a bunch of passes.

For the sake of accuracy you can't just say they "stack" on top of each other in real world recording. The musicians are "compensating" in theory. So the issue really only exists for "each pass".

[Rich Breen]

Originally Posted by propower

20 samples at 96kHz is

20samples/96000samples/second = 0.00028seconds = 0.28msec

Whoops, you dropped a zero: 20 samples = 0.208 msec

...
So is almost a millisecond of any concern? What about 2 or 5 after a bunch of passes.

There's a couple of things getting mixed up here: There's the finite delay of *any* hardware converter; the amount of time the converter itself takes to get the signal in, do what it needs to do and get it out the other end - add to that the transport's delay (firewire or usb or pcie or tbolt). For most current converters an a/d/a trip is sub-millisecond at 96k, and under 2 msec for 44.1k, but this will depend greatly on exactly what converter in what system - Avid's current interfaces are admirably fast - there may be faster out there, but not by much. IME, anything nearing 5 or 6msec becomes a problem in live tracking situations, and anything under 2msec is generally not an issue, but people will argue endlessly about the threshold for this.

What the OP wrote about is that Pro Tools has the ability to compensate for the converter/transport delay *after* the record pass, since it knows what converter it's using - the OP says it is getting placed 21 samples (208 microseconds) late by this algorithm - this may or may not be the case, but is a different issue from converter throughput delay which is a known and universal issue. If Avid's "input delay compensation" is not working correctly, of course it should be fixed, but I gotta say, I'm not gonna be losing sleep over 200usec of error, unless it differs within a stereo pair or multimic'd set, and any experienced engineer knows that members of a phase-critical set should all use the same signal path/converter set (IOW, you don't split pairs/sets over multiple differing interfaces).

[JFreak]

I've said this "a million" times but on a live gig 5ms must not be any kind of a problem. It's like having a floor monitor 1,5m away from your ears. The problem threshold is closer to 10ms

[Matt Hepworth]

Originally Posted by Drew Mazurek

Agreed. Just questioning Matt's 1.3ms figure.

Having said that, if you can discern 220 micro seconds when overdubbing a snare over a kick, I'll give you a million dollars.

1.3ms is the exact same offset, but at 44.1kHz instead of at 96kHz. It's 58 samples at 44.1kHz, which is 1.3ms.

I use 44.1kHz 99% of the time, BTW. So do many of us.

[Drew Mazurek]

Originally Posted by Matt Hepworth

1.3ms is the exact same offset, but at 44.1kHz instead of at 96kHz. It's 58 samples at 44.1kHz, which is 1.3ms.

I use 44.1kHz 99% of the time, BTW. So do many of us.

Sorry, what I meant was I am/was questioning the "build up" aspect of this issue.

I'm going to post some files tomorrow to further examine this.

[propower]

Originally Posted by Rich Breen

Whoops, you dropped a zero: 20 samples = 0.208 msec

Good catch! I actually thought about this when I woke up knowing something was amiss !

Originally Posted by Rich Breen

What the OP wrote about is that Pro Tools has the ability to compensate for the converter/transport delay *after* the record pass, since it knows what converter it's using - the OP says it is getting placed 21 samples (208 microseconds) late by this algorithm - this may or may not be the case,

Exactly! And 1.3msec late at 44.1kHz. All for no apparent reason. PT compensates for all the plugins - why leave the static and completely known D/A time out? Its sloppy engineering.

Originally Posted by Drew Mazurek

For the sake of accuracy you can't just say they "stack" on top of each other in real world recording. The musicians are "compensating" in theory. So the issue really only exists for "each pass".

I don't say they "will" stack. What I do say is that if track 2 plays in perfect time to track 1 it will have this offset error in the timeline. When track 3 comes around - if they play to track 1 then 2 and 3 will be aligned. If they play to track 2 then 1, 2 and 3 will all be offset from one another. And so on as tacking goes on.

Of course we can "get work done" with this error (should it be proven to be there). But how would this not be labeled a bug that just shouldn't be there?

[Drew Mazurek]

Originally Posted by propower

But how would this not be labeled a bug that just shouldn't be there?

It wouldn't/shouldn't be.

[propower]

Originally Posted by Drew Mazurek

It wouldn't/shouldn't be.

If it is proven to be this way I can then introduce (re - acquaint) you with the DDMF MetaPlugin that is the only way I know to compensate for this in Pro Tools. I use it for every interface in Native land that has this problem.