Recorded Tracks Are Offset / Not in Correct Position

[DCMG]

Random issue but happens enough, thought I would ask if this happens to anyone else.

Typical circumstance:

Loop Record Mode> run 4-5 passes> stop transport to find all passes are not in correct position (always early to where they should be).  Luckily I usually am looping to a grid so it's easy to see the new misaligned passes are easily moved by 1/4, measure or whatever and all is well.

Subsequent passes all land in correct position; not unusual for the problem to NOT present itself again for days or a week.

Note: I did have this happen with a manual start (non looping mode) the other day, so it's not just a loop record issue.

No pattern detected yet, and no other timing anomalies with my setup observed ( UA Apollo w/ Presonus  192 providing Optical ins and clock)

TIA.

 

[DeeringAmps]

I’ve seen this when looping and punching in. It was “fixed” back in the Sonar days. I’ve never had issues with ASIO drivers and looping. I have a project for testing to be sure everything is in sync; haven’t tested the latest update yet. I’ve had one project that was problematic in CbB. It was an old project that was started back in X2 or 3. I saved it as a . mid file and imported the audio tracks; haven’t had any more issues. 

tom

[DCMG]

Thanks for the input. Don't recall this issue in SONAR; seems like a recent ( last 2 updates?)

Will do more testing this week, but it's pretty random so far....

[Roger Jeynes]

We've been having a very similar issue intermittently for nearly a year. Recordings of new clips are either offset by 2 seconds (i.e. they are late by 2 seconds), or the last 2 seconds of the clip are cut off. It's been reported, but Cakewalk have been unable to reproduce or fix. As we can't determine in what circumstances it occurs (it seems entirely random) , it's very hard to reproduce: hence why it's been so hard to diagnose.

In our case when we examine the WAV audio file which is associated with the clip it either has 2 seconds of silence at the beginning, or the final 2 seconds of audio is there but not referenced by the clip.

We are using a count-in of 4 beats and a tempo of 120 bpm (=2 seconds), so we thought it was related to count-in or snap, but no luck so far. Snap on or off makes no difference.

Would be really interested to see how your WAV audio files associated with the out-of-sync clips look.

(We're using Allen & Heath Qu24 ASIO driver with Cakewalk 2020.08, but it's been happening in lots of earlier releases)

[DCMG]

17 hours ago, Roger Jeynes said:

We've been having a very similar issue intermittently for nearly a year. Recordings of new clips are either offset by 2 seconds (i.e. they are late by 2 seconds), or the last 2 seconds of the clip are cut off. It's been reported, but Cakewalk have been unable to reproduce or fix. As we can't determine in what circumstances it occurs (it seems entirely random) , it's very hard to reproduce: hence why it's been so hard to diagnose.

In our case when we examine the WAV audio file which is associated with the clip it either has 2 seconds of silence at the beginning, or the final 2 seconds of audio is there but not referenced by the clip.

We are using a count-in of 4 beats and a tempo of 120 bpm (=2 seconds), so we thought it was related to count-in or snap, but no luck so far. Snap on or off makes no difference.

Would be really interested to see how your WAV audio files associated with the out-of-sync clips look.

(We're using Allen & Heath Qu24 ASIO driver with Cakewalk 2020.08, but it's been happening in lots of earlier releases)

Did some testing last night, couldn't get it to happen (or course)

My only clue is I've never had it happen LATE in a session; always right off the bat, then subsequent takes are good once I observe the issue, stop transport and begin a new set of takes ( buffering, length of time program/OS/computer has been on? )

I've started doing a test run of 2-3 looped takes when I've got a client present. I don't tell them why I'm doing it, but I'm checking to make sure it's behaving. Shouldn't have to do that type of stuff to trust your system ( which BTW is a fast CPU, good RAM and all SSDs so no issue there)

Will keep digging.

 

[Roger Jeynes]

It tends to happen earlier in sessions, but not always. However it has never happened on successive takes.  We also wondered if was to do with flushing the buffers, because we sometimes get a (random) audible 'tail' on rewind and re-start - although not at the same time as with this out of sync problem.

We've tried increasing ASIO buffer sizes and increasing latency, and increasing the Cakewalk File System buffer size, but it seems to make no difference. Got a very powerful i7-9700K, lots of memory and M2 SSD, We've also changed the PC last December, and it has persisted across 2 completely different PCs, so  I'd be really surprised if it's a  PC hardware issue.

Freed at Cakewalk has asked us to try and reproduce the problem using a different interface (we have an old MOTU), but of course we haven't been able to because we can't use this for real work - which is when it tends to happen, of course! I'm encouraged that you're using a different audio interface, which possibly takes the spotlight away from Allen & Heath driver.

We're going to try changing this setting in the Config file (just for something to do)

 

[Roger Jeynes]

Just trying some other things to see if we can isolate or clear this problem:

Wondering  what this setting in the config file does, and whether it might be relevant:

Ours is set to 'true' in the config file.

 

We also have other ASIO drivers installed, but not normally active, for other audio interfaces. I noticed that the 'Record Latency Adjustment' setting always resets itself to the first driver in the list, no matter which one we select. (Although 1328 samples is a lot shorter than a 2 second delay)

 

 

[DCMG]

It happens so infrequently you might be waiting days or a week before the changed settings would show if they worked. I'll keep at it too.  Strange elusive issue....

 

Edited September 11, 2020 by DCMG

[John Vere]

You really need to get rid of that generic ASIO driver, that definitely causes problems for me so I found the .dll and nuked it. ( it will be in a Steinberg folder)  It gets installed with Steinberg stuff like Wave Lab or Cubase. 

[Roger Jeynes]

New occurrence yesterday, when the new overdub clip was out of sync by a huge margin (20 seconds!) and the leading part of the new clip truncated by this amount. During recording, the waveform was drawn perfectly  normally. Finding it really hard to go on covering this up with the customers

Edited September 11, 2020 by Roger Jeynes

[John Vere]

Did you read my post and follow through?

 

[DCMG]

On 9/11/2020 at 11:00 AM, Roger Jeynes said:

New occurrence yesterday, when the new overdub clip was out of sync by a huge margin (20 seconds!) and the leading part of the new clip truncated by this amount. During recording, the waveform was drawn perfectly  normally. Finding it really hard to go on covering this up with the customers

Interesting note that the waveform preview is always in correct position, suggesting alignment is correct at moment of capture, then offset upon transport reset. Same always true here as well. I'm going to update all my system info along with typical plugins used so we can identify any commonalities. Regarding the suggestion about generic drivers, I only have the UA Apollo Twin USB drivers present and still have this issue. No conflicting ASIO drivers present.

 

[gustabo]

Get rid of the Generic Low Latency driver, uninstall it!
It's known to cause issues!

[Roger Jeynes]

On 9/12/2020 at 1:30 AM, John Vere said:

Did you read my post and follow through?

 

Hi John - yes, and many thanks.

[John Vere]

Great, The offset is calculated by Cakewalk and it needs correct information which can only be supplied by the ASIO driver. This is why you will see timing offset errors like this in all the other driver modes. 

Have you tried a loopback test? 

Take a midi drum track,  just a kick or snare will do, Freeze it to audio. 

Now patch the output of your interface back to an input and set up a new audio track to record this input. 

Turn OFF input ech for that new track. 

Record the loopback,  and then zoom way in to see if the transients match up. 

If you do this with a 3-5 minute track, you can check at the end of the song to see if it drifts off time. 

 

[Roger Jeynes]

19 hours ago, John Vere said:

Great, The offset is calculated by Cakewalk and it needs correct information which can only be supplied by the ASIO driver. This is why you will see timing offset errors like this in all the other driver modes. 

Have you tried a loopback test? 

Take a midi drum track,  just a kick or snare will do, Freeze it to audio. 

Now patch the output of your interface back to an input and set up a new audio track to record this input. 

Turn OFF input ech for that new track. 

Record the loopback,  and then zoom way in to see if the transients match up. 

If you do this with a 3-5 minute track, you can check at the end of the song to see if it drifts off time. 

 

Thanks, John - really appreciate your interest in this.

A loop-back test shows what I think we might expect: a constant delay of about 1000 samples, which I guess is just the ASIO driver latency (2 x 512 samples)? We're struggling to understand how or why this sometimes causes a huge slip (from 2 to 20 seconds) in the timing and content of a recorded clip, when the waveform is being written normally and at the correct time during recording. (I should add that we haven't seen one in the last 2 days, so your interest is paying off!)

[John Vere]

Well I tested a few different interfaces and everyone of them was bang on if I used ASIO mode. You have something going wrong if your ASIO driver is not syncing up with Cakewalk. You might want to try a different interface. 

 

 

Here was a Behringer USB interface that used a generic Codex 

 

Here is a Crappy Sound Blaster card but with ASIO it seems to be OK.  Notice WDM mode which always seemed to be early in my tests. 

 

 

 

[DCMG]

Yeah, I'm not seeing round trip latency issues offset by 128 samples or something. These are  wholesale "off by 10 seconds" issues.

Then the next immediate round of recording (literally seconds later) ...everything fine.

Odd issue. Yesterday happened mid session, which I haven't encountered. It's a tough one to explain to clients ( when we already labor under the "why not ProTools?" dogma ?

[msmcleod]

The device in the "Record Latency Adjustment" must match the device you're using for record/playback, else all the timing will be off.

Uninstall the Steinberg "Generic Low Latency ASIO driver" if you can - it causes no end of issues, and isn't required (even for Cubase) if you've got an interface that has a native ASIO driver.

[John Vere]

I think there's some confusion here as the OP's  claimed he does not have any other drivers listed. , the screen shot was from Roger who is also having an issue and definitely needs to nuke the Steinberg driver.  

The OP is using a complicated set up with 2 interfaces involve. To test I would go direct from the Apollo via USB and see if the problem persists.