Record Latency Adjustment (audio not midi) ignores manual offset setting

[bgewin]

I was noticing that my bass guitar playing seemed rushy and thought it might be time for another sync test.

I connected a cable from my analog headphone amp's output to an input on my presonus mixer. 

I soloed an analog track, and recorded its output (through the headphone output and analog input above) onto a new track. 

Sure enough, the copied version of the audio was ahead by 1020 samples. No problem, just go into EDIT=> PREFERENCES => AUDIO => SYNC AND CACHING and play with the MANUAL OFFSET under "Record Latency Adjustment" until the incoming wave syncs with the pre-recorded stuff. 

Only thing is, whether I set the offset to 0, 5, 1000, 5000 or even -5000, the new, copied audio is about 1020 samples ahead of the original. The system seems to be completely ignoring the Manual Offset setting. I experimented with checking and un-checking "Use ASIO Reported Latency" and it doesn't make a difference. 

I've tried multiple takes, and closing Cakewalk and going back in; no difference. 

Please help, and thank you.

[John Vere]

In the Preferences/ Sync and Caching dialogue that shows what ASIO device is used to report the latency— is this the same as your ASIO audio interface? 
 

I cover this in a few videos #1 and # 106 

 

Edited May 8, 2022 by John Vere

[bgewin]

Yes John - "Studio Live Series III ASIO (64 in, 64 out)".  This happens to be the only option in the dropdown; there's no other choice. 

 

Edited May 9, 2022 by bgewin

[John Vere]

OK that good (and bad) as it rules out what I thought might be happening. That sometimes other crappy ASIO drivers get in there and mess up the reported RTL figures. 
One thing that will mess this up the reported RTL is using certain look ahead effects that will add additional latency but this is not factored into the calculation. So try bypassing all effects and see if that fixes it.

I myself avoid adding effects until I’m done tracking. But if I do I always use the global bypass effects toggle. 

[bgewin]

Ok thank you John - that works. Man, super bummer but at least there's a workaround. I tried the global effects bypass and that got the timing problem solved, and Cakewalk definitely respects the offset now (changing the offset has an effect now). I have a lot of effects and soft synths in this project. I'll try and figure out which the culprit is an post it here. 

[bvideo]

Is some plugin not reporting its lookahead / plugin delay? (See also Live Input PDC override in the manual). Or maybe just PDC override needed?

Edited May 9, 2022 by bvideo

[John Vere]

Yes PDC is another way to fix the issue. Only thing I don't like about it is it's easy to forget you toggled it. That's why I prefer to use the Global effects bypass because it's usually noticeable that it's toggled.   At least it seems your exports will not suffer as you see in the very last line I highlighted. 

From the PDF Documentation: 

Live Input PDC Override . Enable/disable delay compensation on live tracks, thereby removing the latency during playback and recording of such tracks. Because it's a toggle, you can quickly turn it on to complete your tracking at low latency, and turn it off when finished to hear the track compensated as normal. For details, see “Live Input PDC override”

on page 367.

Live Input PDC override While working with virtual instruments and live input monitored tracks, it is important for audio to be streamed at low latency in order to minimize delay. Although Cakewalk supports streaming audio at very low latency, there are cases where internal buffering can cause additional latency. The most common scenario is when using plug-ins that require Automatic Plug-in Delay Compensation (PDC). PDC is the process of delay compensating other normal tracks so they are synchronized with the delayed audio produced by the plug-ins. Whenever delay compensation takes place on a track that has a live input (an input monitored track or synth track), it is delayed by the required amount to synchronize it with other tracks. In some cases, the delay can be noticeable and make live tracking difficult. The Live Input PDC Override toggle lets you disable delay compensation on live tracks, thereby removing the latency during playback and recording of such tracks. Since it's a toggle, you can quickly turn it on to complete your tracking at low latency, and turn it off when finished to hear the track compensated as normal. Regardless of whether Live Input PDC Override is enabled or disabled, recorded audio is placed on the timeline at the correct position as recorded. Live Input PDC Override is ignored during a bounce/export or freeze operations. 

[David Baay]

14 hours ago, John Vere said:

Regardless of whether Live Input PDC Override is enabled or disabled, recorded audio is placed on the timeline at the correct position as recorded.

This quote from the ref, guide suggests that plugin delay is taken into account when compensating a recording and agrees with my experience. I think something else must be going on to cause the overcompensation the OP is describing. If anything, failure to take plugin delay into account would result in a late, under-compensated recording, and a positive manual offset would fix it. But I just double-checked and adding the notorious TS-64 Transient Shaper to a track did not affect the sample-accurate record compensation I have dialed in though the delay was there when not direct-monitoring the live input or engaging PDC override.

[John Vere]

I guess the best way to figure this out would be to do loop back tests. 

But I’ll let someone else do that as I said I don’t use the PDC. First I avoid adding effects when still in the tracking stage. And then later if I need to record a new track I use the global bypass toggle. 
Sometimes my song sounds better when I turn off the effects ?

Edited May 10, 2022 by John Vere

[bvideo]

Here's my guess at explaining the PDC control:

First, the control affects just tracks with live input, meaning all echo- or record-enabled audio tracks and synth tracks (audio created by MIDI on their associated tracks or by MIDI input). The control enables or disables PDC for just those tracks. Other tracks (non-live) still have PDC enabled.

I think the idea is that you can record along with your PDC (delayed) backing tracks while hearing the live input echoed through the tracks you are recording without PDC-induced delay (i.e. minimal delay equivalent to your round-trip latency). I.e. you are playing in sync with what you hear. When recording is stopped, the material you recorded is moved earlier in time so that it will henceforth play back in time properly compensated with the required PDC of the whole project.

This kind of leaves open all questions about busses or aux tracks that are fed by these live tracks. It's easy enough to imagine that effects on your live tracks that apply plugin delay could be de-compensated, but harder to imagine how busses that mix multiple tracks could disable PDC just for a live input and not for other tracks in the mix.  The manual hints about this in saying:

Quote

Some signal routings can cause tracks to be out of sync when Live Input PDC Override is enabled. To prevent any potential sync problems, follow these suggestions:

• Output the live input tracks directly to the final bus in the signal flow.
• Send live tracks directly to a hardware main.

Also, there are some disclaimers about live-input tracks that already have recorded material on them. When using PDC override on such live tracks, that prerecorded data will play back non-compensated and thus be out of sync with the PDC-compensated tracks. Ugh. So there is a note in the manual:

Quote

Note: If the live track being monitored also contains track data (or MIDI data in the case of a synth track), the streamed track data will not be delay compensated. As a result the recorded track data will not be in sync with other tracks. You should either mute any clips on the live tracks, work with an empty region of the track, or use an entirely new track while recording.

(bold emphasized by me) If you are recording in a PDC-required environment and you are matching against already-recorded material, if any of that material is on a live-input track (echo- or record- enabled) and you play against it, your recorded material will be placed (advanced) in its track not in sync with that prerecorded material.

Therefore, it seems PDC is not necessarily a one-button magic solution to recording with PDC-needing effects, depending on existing routing or preexisting recorded material. The workarounds of the above quotes need to be heeded. Bypassing effects could be a one-button solution, with the obvious limitation that what you're hearing when you record is not the same sound as the intended sound with effects. (But that could sometimes sound better anyway ?)

[David Baay]

Yes there are situations that PDC override can't accommodate (e.g. having both recorded audio and live input on the same track or having a routing that takes the live input through the plugin that's adding the delay). But none of that is really applicable to the OP's issue since he's reporting over-compensation of recorded audio and that Manual Offset can't compensate for it neither of which should be affected by PDC override.

One thing I'm wondering about is this:

On 5/7/2022 at 9:29 PM, bgewin said:

I connected a cable from my analog headphone amp's output to an input on my presonus mixer. 

Is the headphone amp getting signal from an output on the same Presonus mixer/interface, and is it using ASIO driver mode?

If using ASIO drive mode, you can use the CEntrance Latency Tester to measure the actual latency and calculate the exact Manual Offset as CEntrance Measured RTL minus CbB-Reported RTL.

https://centrance.com/driverfolder/CE_LTU_37.zip

 

[bvideo]

Yes, the seeming failure to track the manual offset is not explained by known PDC factors.

However, the constant 1020 sample offset could possibly still be explained if we knew about the conditions of the soloed track, buses, and live input settings, not to mention which effects were there.

Dave, your suggestion for using the latency monitor is a great one for breaking down the elements of bgewin's audio interface situation, starting with a bare project.

Edited May 10, 2022 by bvideo

[David Baay]

Yes, this is something you would definitely want to try reproducing in the simplest possible project. If it turns out to be project-specific, it'll be difficult to get to the bottom of it without examining a copy of the project directly.