questions about Latency/Delay compensation in T5 and T6

[Kang]

I seem to remember in T3 that you could track with plugins on your tracks, but not on the master if you wanted your overdubs to be time accurate.

I also remember doing tests in T3 in which I ended up using the time-delay with "auto-detect" feature in the properties menu of each input in order to get the most time accurate overdubs. You plug an output into an input, it would click three times and give me an amount to offset each input by. I did the same test last night and have found that I only ever get one click and it gives me an offset (28ms last night), but it's most accurate on the overdubs to leave it at 0.00ms.

Am I totally off or has anything changed? I would just like to be knowledgeable about any compensation that is or is not happening.

Lastly, on racks and aux sends do I have to be aware of plugin latency? If I aux send a bunch of drum tracks to another track with the aux return and use a plugin with latency on the return track will this throw things off when I try to bring it up in parallel?

Thank you for any insight.

[Kang]

Surprised no one else was interested in this...

I decided to do some more tests today and while I feel pretty good about it, I got different seemingly different results than last time. In no way am I claiming that this is a proper test, but I would be interested in any feedback.

I recorded the click from my headphone out onto a track through input 1. Then I turned off the click and recorded the already recorded click track channel the same way to another track. They were off by quite a bit, so ran 'auto detect' from the input properties and set the inputs to the result which was 51ms. Now the recordings were on time give or take about 1/10th of a ms.

I messed around with my highest latency plugins on the tracks and on the master channel. The recorded tracks always lined up. I even tried deleting plugins mid-recording and while it lets you do that it seems like the plugin is still enabled/effective until the recording stops.

From this I gather that delay compensation works fine on the master and tracks, and that the auto-detect feature on the inputs is indeed a necessity. It's also important to note that your offset is dependent on your buffer size. I was using 1024 samples for this test. Auto-detect compensation time was always more than the buffer though.

My only concern is that I got different results than last time. I suspect I may have been recording the internal click each time and not the 'already recorded to a track' click for the overdubs.

Any thoughts? Is this how you guys have always presumed tracktion to work?

[gigazaga]

I recorded the click from my headphone out onto a track through input 1. Then I turned off the click and recorded the already recorded click track channel the same way to another track. They were off by quite a bit, so ran 'auto detect' from the input properties and set the inputs to the result which was 51ms. Now the recordings were on time give or take about 1/10th of a ms.

I messed around with my highest latency plugins on the tracks and on the master channel. The recorded tracks always lined up. I even tried deleting plugins mid-recording and while it lets you do that it seems like the plugin is still enabled/effective until the recording stops.

From this I gather that delay compensation works fine on the master and tracks, and that the auto-detect feature on the inputs is indeed a necessity. It's also important to note that your offset is dependent on your buffer size. I was using 1024 samples for this test. Auto-detect compensation time was always more than the buffer though.

I have been wondering about this too and running similar tests. I don't have any conclusions but some buffer settings seem to behave differently than others. It would be interesting to know what happens if you try different buffer settings.

Also, what OS are you running?

[Kang]

I have been wondering about this too and running similar tests. I don't have any conclusions but some buffer settings seem to behave differently than others. It would be interesting to know what happens if you try different buffer settings.

Also, what OS are you running?

Those tests were running in OSX 10.10.2, but I just tried windows 7 with multiple buffers and got similar results, except the time adjust settings were much less and always less than the buffer in this case. Strangely at super low buffer settings the auto-detect adjustment time was negative, but still provided the most accurate overdubs (otherwise overdubs would fall earlier than the track recorded from?!?!). In both tests even with time adjustment they were always off by about 1/10th of a ms (which can be considered negligible, but still worth noting).

I wanted to test the claim in the "so...tracktion" thread in the host forum that Tracktion will not update plugins with dynamic latency, but I couldn't find any that did that so I won't worry about it.

[lopsy]

I asked a question about adjusting for latency a few weeks ago. In the end what seemed to sort it was updating the asio driver for my audio interface.

[gigazaga]

Those tests were running in OSX 10.10.2, but I just tried windows 7 with multiple buffers and got similar results, except the time adjust settings were much less and always less than the buffer in this case. Strangely at super low buffer settings the auto-detect adjustment time was negative, but still provided the most accurate overdubs (otherwise overdubs would fall earlier than the track recorded from?!?!). In both tests even with time adjustment they were always off by about 1/10th of a ms (which can be considered negligible, but still worth noting).

My tests on OS X confirm that running the Auto-Detect is necessary to get proper alignment of overdubs. The really interesting thing is that there is a formula to it - at least on OS X. Make note of the calculated latency reported on the Settings > Audio Devices > Audio buffer size property. You can predict the Auto-Detect Time Adjust value using this formula:

Time Adjust = BufferDelay * 2 + 2.2

At least on my system, if I plug in that value for Time Adjust, the overdub alignment is the same as running Auto-Detect.

Would you check if this holds true for your systems as well?

I will test on Windows too. I think latency compensation could be improved in T6 even without running Auto-Detect if that formula holds up for other systems.

On OS X I'm using:

PreSonus iTwo (USB Class Compliant - no drivers), T6 6.0.23 64-bit, OS X 10.10.2.
For the Auto-Detect loop back, I put mic 1 on the grill of my studio monitor (with hardware input monitoring OFF)


Update1: The calculation holds for OS X at 96k sample rate, if you lower than constant to 1.8ms.
Update2: The formula does not hold for Windows Audio or ASIO

[chico.co.uk]

Those tests were running in OSX 10.10.2, but I just tried windows 7 with multiple buffers and got similar results, except the time adjust settings were much less and always less than the buffer in this case. Strangely at super low buffer settings the auto-detect adjustment time was negative, but still provided the most accurate overdubs (otherwise overdubs would fall earlier than the track recorded from?!?!). In both tests even with time adjustment they were always off by about 1/10th of a ms (which can be considered negligible, but still worth noting).

My tests on OS X confirm that running the Auto-Detect is necessary to get proper alignment of overdubs. The really interesting thing is that there is a formula to it - at least on OS X. Make note of the calculated latency reported on the Settings > Audio Devices > Audio buffer size property. You can predict the Auto-Detect Time Adjust value using this formula:

Time Adjust = BufferDelay * 2 + 2.2

At least on my system, if I plug in that value for Time Adjust, the overdub alignment is the same as running Auto-Detect.

Would you check if this holds true for your systems as well?

I will test on Windows too. I think latency compensation could be improved in T6 even without running Auto-Detect if that formula holds up for other systems.

On OS X I'm using:

PreSonus iTwo (USB Class Compliant - no drivers), T6 6.0.24 64-bit, OS X 10.10.2.
For the Auto-Detect loop back, I put mic 1 on the grill of my studio monitor (with hardware input monitoring OFF)


Update: The calculation holds for OS X at 96k sample rate, if you lower than constant to 1.8ms.

I don't know how useful it'll be to try to reverse-engineer how the latency compensation is calculated, or why that would be useful, to an end user.

You do want to use the Auto-detect, to ensure your tracks align, because the calculation that comes up with is going to be dependant on what outboard hardware you use, and the latency they introduce. Figuring out your own equation, and using that is actually more hassle than just looping the output to the input, and leaving T6 to calculate it.

[gigazaga]

I don't know how useful it'll be to try to reverse-engineer how the latency compensation is calculated, or why that would be useful, to an end user.

You do want to use the Auto-detect, to ensure your tracks align, because the calculation that comes up with is going to be dependant on what outboard hardware you use, and the latency they introduce. Figuring out your own equation, and using that is actually more hassle than just looping the output to the input, and leaving T6 to calculate it.

Right I understand. The amount the latency compensation without auto-detect, seems more dependent on which driver technology is engaged Core Audio, ASIO, DirectSound, or Windows Audio. My testing shows similar results using different audio interfaces within the same driver type.

The loopback Auto-Detect is required for all types to be close.

[Kang]

For me OSX is giving predictable auto adjust times with a .1 margin of error. It's (Buffer X 2) + 4.7 (give or take 1/10th) though, so not exactly the same as you. This is with a Focusrite Saffire Pro 40.

Thanks for the input. I am feeling better knowing what to expect and that it seems to be working predictably and accurately.

[Kang]

T6 6.0.24 64-bit

Was this a typo or are you a step ahead?

[gigazaga]

Was this a typo or are you a step ahead?

Something like that. I updated the post.