Manual Delay Comp Problem

[WinTaper]

I'm having a problem with delay compensation. I've setup an analog loop from output to input. I have determined that the recorded track is off by 72 samples. That is, the recorded track is 72 samples later than the source track.

According to what I've read, I should be able to enter a "User Offset" in track view. However, no value I can enter moves the recorded track up. If I put positive values in … 72, 144, etc and re-record, the recorded track never moves up. If I put negative values in, the recorded track ends up moving the wrong way (even later). So it looks like positive values should work, but they aren't.

So how do I get the recorded tracks to align to existing ones? I have Sonar on the same machine, and it has an option for manual sample offset where if I enter +72 and perform the same test, the tracks are sample perfect.

[Dism]

Originally Posted by WinTaper

I'm having a problem with delay compensation. I've setup an analog loop from output to input. I have determined that the recorded track is off by 72 samples. That is, the recorded track is 72 samples later than the source track.

According to what I've read, I should be able to enter a "User Offset" in track view. However, no value I can enter moves the recorded track up. If I put positive values in … 72, 144, etc and re-record, the recorded track never moves up. If I put negative values in, the recorded track ends up moving the wrong way (even later). So it looks like positive values should work, but they aren't.

So how do I get the recorded tracks to align to existing ones? I have Sonar on the same machine, and it has an option for manual sample offset where if I enter +72 and perform the same test, the tracks are sample perfect.

I think you may be confused as to how delay compensation works.

Delay compensation, manual or otherwise, only moves audio forward and not back. That is to say, if you are compensating for a track being 72 samples late, Pro Tools should move all the other tracks 72 samples later, rather than the one track 72 samples sooner.

Make sense?

[WinTaper]

No, I've got it right. You are describing plugin delay comp on playback. I'm talking about input (hardware) delay compensation when recording - specifically, I need compensate by a fixed amount.

It works the same in Cubase and Sonar (and it works in those). Regardless, +72 and -72 should compensate in opposite directions and they do not. Positive numbers do nothing.

Looks like a bug. I guess I can nudge all new tracks into alignment.

[WinTaper]

<bump>

[WinTaper]

OK, the help file says ...

Pro Tools HD accounts for converter delays when using Automatic Delay Compensation. However, when using non-HD hardware, System Delay only displays internal delay and does not take into account any latency incurred by the analog-to-digital (ADC) or digital-to-analog (DAC) converters in your audio interface.

So, how do I manually enter the the additional latency Pro-Tools cannot measure? I know exactly what that value is. There must be some setting I am missing. No one has encountered this?

FYI, I'm using an RME HDSP-9652 (PCI) with Focusrite pre-amps connected via lightpipe.

[AdamPT8]

Is it the recorded track that is 72 samples behind the rest of the tracks?

[DigiTechSupt]

Originally Posted by WinTaper

I'm having a problem with delay compensation. I've setup an analog loop from output to input. I have determined that the recorded track is off by 72 samples. That is, the recorded track is 72 samples later than the source track.

According to what I've read, I should be able to enter a "User Offset" in track view. However, no value I can enter moves the recorded track up. If I put positive values in … 72, 144, etc and re-record, the recorded track never moves up. If I put negative values in, the recorded track ends up moving the wrong way (even later). So it looks like positive values should work, but they aren't.

So how do I get the recorded tracks to align to existing ones? I have Sonar on the same machine, and it has an option for manual sample offset where if I enter +72 and perform the same test, the tracks are sample perfect.

You use the H/W Insert Delay offset, as indicated by Albee. This info starts on page 962 of the Pro Tools 9.0 Reference Guide.

First of all, converting samples to milliseconds is sample-rate dependent - so that's a pretty lousy way to handle it. Secondly, there's a rounding error. Thirdly, it only applies to hardware inserts - not inputs. Fourthly, it applies to playback, not record.

No, it's not sample-rate dependent. The hardware has a fixed latency in milliseconds. If you change the sample rate, you'll just see the number of samples of delay change, however the overall time in ms will not change.

Example - 72 samples at 44.1k is 1.633ms (rounded to the 3rd significant digit). If you were to measure that in a 88.2 k session, the number of samples would change to 144, but the time in ms would remain the same.

[WinTaper]

Sorry, but this answer is wrong. Frankly, I expected more from digi.

How many times do we need to say - we are talking about INPUTS not INSERTS? Or have you found some way to record thru inserts?

also, the buffer setting selections on my RME are in samples not milliseconds. Besides the fact that the HW Insert Comp rounds millisecs to 2 decimal points - introducing rounding errors.

Sonar, Cubase, Nuendo all get this right. PT9 does not. Like it or not - its a bug - or at best a missing capability.

I was looking forward to using PT but if this problem isn't corrected, the product is useless.

And the level of denial around here is ridiculous.

[DigiTechSupt]

Originally Posted by WinTaper

Sorry, but this answer is wrong. Frankly, I expected more from digi.

How many times do we need to say - we are talking about INPUTS not INSERTS? Or have you found some way to record thru inserts?

also, the buffer setting selections on my RME are in samples not milliseconds. Besides the fact that the HW Insert Comp rounds millisecs to 2 decimal points - introducing rounding errors.

Sonar, Cubase, Nuendo all get this right. PT9 does not. Like it or not - its a bug - or at best a missing capability.

I was looking forward to using PT but if this problem isn't corrected, the product is useless.

And the level of denial around here is ridiculous.

I should have been more explicit and I also referenced the wrong person.

You don't have to say anything more than once - I get it. Sometimes, though, given the hundreds of DUC posts I'm not able to give every one of them the amount of attention it needs. The comments about someone being surprised that no one from Avid has chimed in is one of the reasons I wanted to at least put something in this thread, though I think, in hindsight, that it was premature.


SteveBoker had it right regarding the H/W Insert Delay in this post:

http://duc.avid.com/showpost.php?p=1711016&postcount=30

Now, unless I'm mistaken, that should work for you. Yes, I know you're NOT using inserts, but we're just doing this as a workaround. I should have been more clear on that.

And, yes, the ability to manually compensate for delays has not been fully implemented yet, for various reasons.

One thing I wanted to point out is that delays in interfaces should automatically be compensated for via the ASIO or Core Audio polling that occurs at driver level and the only manual compensation that should be needed is when you have an external device in your recording chain that's inducing additional delays.

I did want to point something out, though - you say:

also, the buffer setting selections on my RME are in samples not milliseconds.

The RME is your interface you're using for Pro Tools, correct? If so, it should automatically be compensated for as long as it's reporting it's correct delays via the ASIO or Core Audio driver. The only delay you should have to compensate for is for the device(s) between the microphone and the RME. Is that what you're doing? The buffer in the RME, if it's the primary Pro Tools interface, is automatically compensated for.

[bigredsound1]

Digi support Tech,
I enjoy recording to tape and porting that directly off the repro head into my Daw. Not a problem when recording the main tracks, but overdubs require a record offset to timestamp the audio and have it slip back in time. My current daw allows me to offset the record timestamp by up to 64000 samples. What is the max number of samples -> converted into milliseconds that can be used for the H/W Insert Delay? My typical sample delays at 88.2k are 7772 at 30 ips and approximately 15,000 at 15 ips. So can this amount of delay be corrected for using the H/W Insert delay?

Originally Posted by DigiTechSupt

I should have been more explicit and I also referenced the wrong person.

You don't have to say anything more than once - I get it. Sometimes, though, given the hundreds of DUC posts I'm not able to give every one of them the amount of attention it needs. The comments about someone being surprised that no one from Avid has chimed in is one of the reasons I wanted to at least put something in this thread, though I think, in hindsight, that it was premature.


SteveBoker had it right regarding the H/W Insert Delay in this post:

http://duc.avid.com/showpost.php?p=1711016&postcount=30

Now, unless I'm mistaken, that should work for you. Yes, I know you're NOT using inserts, but we're just doing this as a workaround. I should have been more clear on that.

And, yes, the ability to manually compensate for delays has not been fully implemented yet, for various reasons.

One thing I wanted to point out is that delays in interfaces should automatically be compensated for via the ASIO or Core Audio polling that occurs at driver level and the only manual compensation that should be needed is when you have an external device in your recording chain that's inducing additional delays.

I did want to point something out, though - you say:



The RME is your interface you're using for Pro Tools, correct? If so, it should automatically be compensated for as long as it's reporting it's correct delays via the ASIO or Core Audio driver. The only delay you should have to compensate for is for the device(s) between the microphone and the RME. Is that what you're doing? The buffer in the RME, if it's the primary Pro Tools interface, is automatically compensated for.