... who's Cris, for Pete's sake?

My God, who's this Peter dude?

OK last time OP posted was a month ago, so yep let's leave it to Peter - sorry....

For the record, this is still reproducible in X3d - the first pass is laid down late by approximately the same amount as inbound audio latency, and each subsequent pass is later still be by the same amount. I'm just punching in the middle 2 bars of a 4-bar loop, and re-recording the metronome click via digital loopback that is normally perfectly compensated when loop-recording without punch-in.

>For the record, this is still reproducible in X1d
 
You mean X3D? Does anybody have an issue number for this? Thanks..

I ran into this again today. It would be nice to see where this issue is on the 'to do' list at the bakery.
 
I recorded 10 loop takes and had to nudge the last few takes to be in sync with the rest of the audio.

Has anyone done research to find out if the drift variance is directly related to the sound card drivers or not? Is it related to the buffer size?

It would be nice to have a table we could use to manually change the recorded loops to sync the audio it was recorded with. Such as, if you record x amount of loops, each subsequent recording needs to be offset by x amount of ticks and so on.

It would be nice to have real steps to repro like #28.
(Who's Fred? )

Guitarmech111
 
Has anyone done research to find out if the drift variance is directly related to the sound card drivers or not? Is it related to the buffer size?

I haven't done exhaustive testing, and since no one else has reported numbers, I don't know how typical my results are, but I believe it is proportional to buffer size with some additional fudge factor that probably varies with the interface driver. Excerpt from my post #16:
 
Each take is 172 samples later than the previous one - about 20 samples more than half my total latency.
 
Interestingly, if I enter that value as a Manual Offset, then all of the takes are 172 samples late, but the error is not cumulative. Oddly, though, I have to enter it as a negative offset (i.e. decompensation) rather than the positive value you would expect would be needed to compensate for latency.
 
If you really want to know what it is in your environment, I suggest you dial in your analog recording compensation to give you perfectly compensated re-recording by analog loopback, and then do some tests, re-recording the audio metronome output, and seeing how much later the first transient is in each iteration.

I discovered something interesting and useful about this issue. If you disable Use ASIO Reported Latency and set the Manual Offset to 0 (i.e. disable all record latency compensation), the problem of cumulative latency compensation errors is eliminated. All takes will be late but by the same amount. This makes it much easier to correct the timing after recording, and if you record with a small enough ASIO buffer, you might even decide the missing compensation is not an issue.
 
 

I ran into this issue with my first project in the Sonar X series, in this case X3d. I was doing loop recording with punch-in and punch-out set up and noticed the takes were progressively out of sync when recording stopped. So much so that when I stopped the loop before the punch-in time, a last partial clip was created containing the tail end of the last take's audio data which was cut off. I tried this forum's search engine to find if anyone was experiencing the same problem and solutions. This search engine doesn't seem to work, so I googled up the problem and found the relevant threads. The solution that I saw was to uncheck "Use ASIO Reported Latency" and set "Manual Offset" to zero. I did exactly that and it was smooth sailing there after.