Recorded Audio Displaced By ~1000 Samples

[Thatguitarguy]

Hi all,

This problem has been plaguing me all week and the lack of viable solutions I'm finding online is making me nervous. Hopefully someone on here can help me out.

Just to clarify up top: I've had this problem twice now. The first time, I thought it was brought on by drivers I downloaded for another interface. The only solution that worked was a clean wipe of my whole computer. Now it's randomly back and, like the first time, trashing Pro Tools prefs / reinstalling Pro Tools hasn't helped. In both cases, I was recording with no issues for months prior to the problem cropping up.

I'm running Pro Tools 2021 on a 2020 M1 Macbook Air recording through a Scarlett 2i2. After I record, the audio I track gets bumped backwards by somewhere between 1200 and 2200 samples, depending on the buffer size. Here are the numbers I came up with after bussing a click track to a new track within the DAW and then comparing it to a click track I ran out of (and then back into) the Scarlett:

64 buffer: -2200 samples
256 buffer: -2000 samples
1024 buffer: -1200 samples

This happens in a completely fresh session - no plugins or anything.

I tried different Scarlett interface through a different USB port, and got the same problem but with a smaller margin (-800 samples or so at a 256 buffer). The inconsistency has me very confused. I'm reading that the problem may lie with the way PT is communicating with the Focusrite, some inaccessible compensation value that is being miscalculated. If that's the case I'm at a complete loss for how to proceed here.

Thank you to anyone with some insight! Specs below (let me know if you need more info)

---------

Model Name: MacBook Air
Model Identifier: MacBookAir10,1
Chip: Apple M1
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 16 GB

OS: Big Sur v11.5.2
Pro Tools Version: 2021.7.0

Peripherals:

Hiearcool USB C Hub attached to ->
AOC Monitor (via HDMI)
Focusrite Scarlet 2i2
Orico USB 3.0 hub attached to ->
Seagate Barracuda Fast SSD (1tb)
USB Optical Mouse
iLok
HD Web Camera

[Thatguitarguy]

Okay, so I'm not sure how I missed this before, but yes - delay compensation is on and seems to be way overcompensating. I attached screenshots of my mix window and the click experiment run with and without delay comp on at various buffer speeds.

I'm seeing a delay value of 1024 samples on the click track I created. I don't know if that's the root of this problem or just a byproduct of it ~ don't have a super clear understanding of how delay compensation works behind the scenes.

Any insight here is helpful - thank you!

[Darryl Ramm]

First thanks for posting screenshots of your mix window. I can just make out the labels, enough to see routing that does not make sense and when done on my system also produced the same 1024 sample latency. And that's independent of the playback engine IO buffer setting since it's on an aux track, and Pro Tools is using a 1024 sample playback buffer for the aux (at least at the sample rate you are using).

None of this makes sense. Why have a click plugin on this aux insert? And more, why do have the insert looping back between Bus 1 and Bus 1&2? Just don't do that.

If you are trying to use a click plugin then just KISS, stuff it on an instrument track, with no input and send it's output to where you need it (headphones, main out etc.).

If you are trying to understand latency and latency comp, you are messing with the wrong plugin as an experiment, and you are running headlong into the split/buffers in Pro Tools, the IO buffer you control in the playback settings and the fixed size playback buffer pro tools is using here for the aux. This stuff has been widely discussed on DUC and now you know some key words you'll be able to find those threads and have a read if you want.

[Top Jimmy]

Delay compensation can be broken and I think that’s what you are seeing. There are two kinds of delay compensation going on under the hood. One is real-time, and the other is post-shift. Real-time happens during playback while post-shift happens after ending a recording.

Serial bussing can break delay compensation. Bussing an audio track in record to another track in record will break delay compensation including via hardware I/O. When you have both stereo and mono busses set up for a pair of paths, bussing mono from the first to the second will break delay compensation.

If you want to make an honest test, print a test click on an audio track. After printing, route that track to another via a bus and run the test. Then route the print track to a hardware output and back in to another audio track and run the test. Last, try the hardware I/O inserted on the print track as a hardware insert and bus to another track and run the test.

[albee1952]

One more thing that can mess up Delay Comp is having a send that goes nowhere. Example; you send a guitar track to an AUX with a reverb. Then you change your mind and delete the AUX track. If the send is still on the guitar track, its going to mess things up.

[Thatguitarguy]

Hey yall, happy new year. Thank you all for your replies - and for pointing out the flaws in my initial test.

I was getting sloppy with my routing by the time I posted to this thread but the whole reason I did these tests in the first place was because there is an intermittent but very audible "bumping" backwards of all recorded audio. I say intermittent because I've been recording for the last few weeks with no problems, but when I fired up Pro Tools yesterday it was back and has not gone away.

I did the test again - hopefully in a more logical way (no tracks routed into themselves, no running the whole test from a click aux insert). You can see that the click from the hardware bounce is significantly earlier than the ones bussed within the daw.

Any thoughts?

Step 1.jpg

Step 2.jpg

Step 3.jpg

Results.jpg

[Darryl Ramm]

Still not sure exactly what you are doing, what IO buffer size?, sample rate, delay comp on, ignore errors on? etc. what are you seeing shown as delay comp latencies etc. Post your test session online somewhere

[Thatguitarguy]

Buffer size: 256
Sample rate: 48k
Delay comp and ignore errors don't seem to make a difference in delay time anymore. Delay comp latency values are zeros across the board.

Here's the session folder: https://we.tl/t-pZLjexXHV8

Seeing a "System Delay" of 1108 samples on the session info screen - could that be the source of problems?

Screen Shot 2022-01-01 at 9.52.22 PM.png

[Darryl Ramm]

Originally Posted by Thatguitarguy

Buffer size: 256
Sample rate: 48k
Delay comp and ignore errors don't seem to make a difference in delay time anymore. Delay comp latency values are zeros across the board.

Good! That's expected.

Here's the session folder: https://we.tl/t-pZLjexXHV8

Seeing a "System Delay" of 1108 samples on the session info screen - could that be the source of problems?

Attachment 15360

I'll have a play with this since I was just chasing down some MADI problems so have a system in pieces in front of me.

BTW ignore errors will add real-time latency to what you hear while playing, just one reason not to use it unless absolutely needed (by default leave it off).

And to be clear your "hardware IO" is line level out on the 2i2 into a line level input? You are not say playing into a monitor/speaker and recording the audio again with a Mic? Or going through anything else like a mixer or other external box?

[Darryl Ramm]

"System Delay" being reported is what Pro Tools thinks the longest delay though the DAW is. That number is not likely an error, you should be able to understand the contributions to this/where the number comes from. I want to see what the session is doing.