Can TB3 be the only connection to the Mac?

[Darryl Ramm]

All audio tracks in Pro Tools when using CoreAudio or ASIO interfaces get their input moved according to the latency reported by the driver. This happen automatically, you cannot prevent it. It happens independently of having ADC enabled. DAWs have to do this or things would break terribly.

Regardless of whether what the driver reports is the wrong or correct latency this happens. BScout is pointing out there driver does not make adjustments to what it reports to match routed signal latencies (and today it really could not), and again it's interesting that it sounds like DAD de prioritized aligning the analog signals, and if I had one of these boxes in front or me I'd be curious to characterize all the different latencies, including pure hardware monitoring latencies, for different signal routes.

There is some belief that Pro Tools audio input recording adjustment does not include conversion latency... that is not my understanding of how this works, and to do so Pro Tools would have to ignore the conversion latency information provided by the driver (what you are seeing in those extra metrics in RTL Utility). And this would also make no sense since conversion latency clearly is factored into the RTL time used to apply ADC to H/W inserts.

As long as we are not talking huge number of sample errors here, the issue you need to avoid is phase offsets on different inputs, if you are only using the ADC/Analog inputs then it's not going to be an issue.

You have RTL Utility, so you can see what the driver is reporting and you can see there is a difference here at least in RTL latency. You just can't measure the separate input or output part of the latency without additional test hardware.... but you can play with making adjustments to align the different inputs like I talked about in my previous post, you don't need to know absolute values to do that.

[BScout]

Originally Posted by Darryl Ramm

and again it's interesting that it sounds like DAD de prioritized aligning the analog signals, and if I had one of these boxes in front or me I'd be curious to characterize all the different latencies, including pure hardware monitoring latencies, for different signal routes.

Appendix E of the MTRX manual (or the AX32 manual) has these latencies for the full size MTRX (including which are fixed and which are variable depending on clock speed.)
The MTRX Studio manual does not have this info but Jeff did put them up in one of his posts on the MTRX Studio.

DAD did prioritize aligning its analogue signals for its converters (amongst their products) with the DADlink protocol across fibre (thereby being able to use multiple boxes but having the signals aligned at the receiving system despite "expansion" boxes going through additional stages of DD conversion)

Overall, there are a lot of options for signals with these boxes. And some of those can be expanded with even more options that will have variable delay.
Looking at the MTRX Studio: analogue input, ADAT input, Dante input, thunderbolt input, And then all the digital channels could have have AD converters attached which will have all their own latencies. And all of this can be per channel.
A driver being able to report all this is to the DAW is just not a feasible system.
Which is why I push for Pro Tools just adding a delay row on Pro Tools input tab (in samples)

And there's another consideration (which pushes all this talk of sample alignment/delay comp into the corner): even if you could perfectly sample delay, for analogue signals it still won't necessarily be accurate because the signal can be sub-samples off. When I set up hardware insert delays, I do the phase inversion and measure the sum with the original signal to find the setting with the largest dip/cancellation. Because with all the filters involved and oversampling on ADC and DAC design, it won't be perfect.
If I want to do perfect parallel processing with analogue gear, it has to happen in the analogue domain and then returned back for both the processed and dry signal.

For Shawn, you have Logic's reported numbers. Those will be the same numbers Pro Tools will compensate for when using the TB3 connection. And you have the RTL numbers.
Compare the two. The difference is the amount that isn't going to be compensated.
Generally this stuff doesn't matter. Only when perfect phase arrival matters. I have one studio where 32 channels use one converter and 32 channels use a different converter (both feed MADI to the audio interface.) They aren't aligned to each other because the ADC chips have different conversion times. On the patchbay we have them marked in different colours to remind us not to split channels over the two converters when it's necessary for micing (like top and bottom snare should stay on one or the other.) Same for external gear. For instance, we'll mult mic-pre outs to a compressor and send the return of the compressor to Pro Tools. So we have both the dry and compressed coming on separate tracks to Pro Tools. One time, an assistant put the compressor return on the other converter and, of course, in Pro Tools the alignment was bad/destructive so full frequency ranges were getting cancelled out when summed together. Just making sure they were on the same converter fixed that.

[shawnhonsberger]

Thank you @BScout and Darryl Ramm!

I appreciate all the explanations. This is all very helpful!

Re BScout:

For Shawn, you have Logic's reported numbers. Those will be the same numbers Pro Tools will compensate for when using the TB3 connection. And you have the RTL numbers.
Compare the two. The difference is the amount that isn't going to be compensated.

The RTL measurement is 1.8ms at 96k with a 64 sample buffer (presumably what Pro Tools will really be), while Logic Pro's measurement is .9ms at 96k with 32 sample buffer. It makes sense that Logic's is half 1.8ms at .9ms, and it's clearly getting that from the driver's reported latency of 90 samples at a 32 sample buffer.

What we don't exactly know is why the reported RTL is always 27 samples less than the measured RTL at any sample rate or buffer size. Whether that will mean anything in the end is another thing entirely.

Still, interesting stuff..

After much consideration and encouragements, I'll probably start with software monitoring and try to make 1.8ms at 96k with a 64 sample buffer work (compensated at input at 77 samples).

And if it doesn't, I'll do hardware monitoring which should be around 33 samples: (input conversion latency = 11 + input safety offset = 2 + output conversation latency = 11 + output safety offset = 2 + the system delay of 7 samples on the digital matrix and SPQ = 33 total samples). I assume it will also get compensated at input by 77 samples as it's what the driver reports as the input latency, but I'm not sure.

[BScout]

Originally Posted by shawnhonsberger

What we don't exactly know is why the reported RTL is always 27 samples less than the measured RTL at any sample rate or buffer size. Whether that will mean anything in the end is another thing entirely.

Sorry, I didn't see this question earlier. No mystery. That's CoreAudio's safety buffer that is required. RME has written about this but it is implemented by all Core Audio interfaces. I'll just quote RME's notes (but realize all CoreAudio drivers have it and it varies based on the need of the device. In the case of the TB3 driver, it is 27 samples)

From RME:

Core Audio's Safety Offset
Under OS X, every audio interface has to use a so called Safety Offset, otherwise Core Audio won't operate click-free. The Fireface UC uses a safety offset of 16 samples. This offset is sig- nalled to the system, and the software can calculate and display the total latency of buffer size plus AD/DA offset plus 2 x Safety Offset plus Safety Buffer for the current sample rate.

and why the discrepancy with RTL

Core Audio (Mac OS X) allow for the signalling of an offset value to correct buffer independent delays, like AD- and DA-conversion or the Safety Buffer described below. An analog loopback test will then show no offset, because the application shifts the recorded data accordingly. Because in real world operation analog record and playback is unavoidable, the drivers include an offset value matching the Fireface's converter delays.
Therefore, in a digital loopback test a negative offset of about 3 ms occurs. This is no real problem, because this way of working is more than rare, and usually the offset can be compensated manually within the application. Additionally, keep in mind that even when using the digital I/Os usually at some place an AD- and DA-conversion is involved (no sound without...).

They are talking about their hardware but the same thing happens with any CoreAudio driver. This is from the FirefaceUC which uses a 16 sample buffer. Obviously DAD's driver uses a 27 sample buffer.

[Darryl Ramm]

BScout, sorry I don't see how any of that RME discussion is relevant here. I'm familiar with digital loop back being being lower latency than analog, and all the effects of that in hardware inserts and how things won't line up becasue reality diverges from the driver reported hardware conversion + saftey latency metrics etc.

The input and output safety offset here reported by the drivers is 2 samples. That is included in the total driver reported latency. RTL Utility shows all these values. RME and DAD interfaces both provide safety latency info. I can't see how it is possible to tell which of or if both of the DAD safety latency and hardware conversion latency reported by the driver is incorrect for this particular analog route.

These systems are doing complex routing, of different types they can't have a single latency value. Hopefully we all agree on that. So DAD developers have to pick some latency for the driver to tell CoreAudio. They picked something, seemingly closer to the ADAT/digital latencies. But they had to pick something. They might play jigger pokey on any of the latency components reported by the driver, we have no idea what is going on internally with these components unless DAD says so. Once you realize they have to pick a number that's kinda close and kinda works for most routing uses then it is not really important and there is nowhere the difference "comes from" which seems to be what is being asked here ... it comes from them picking a number... and the actual latency for this path being different.

You cannot extrapolate a complete picture about what the latency components actually are for the whole signal flow though driver, and hardware. All mere mortals can do is measure that total RTL latency, and we get to see what (somewhere slightly wrong) values the driver provides but we don't know which of the supplied latency component values is "wrong", or where in this complex systems it is actually spending time. We cannot attribute that only to differences in the driver safety offset (neither with an RTL measurement can we say what fraction of the difference belongs to input or output) but neither does it matter.

And neither does *waving hands exasperated* any of this actually matter. There is no problem here, Shawn needs to get going on setting up his Atmos monitoring system and actually tracking with his system, in talking to him today he has more than enough skills to get going with software monitoring and if not then use DADman monitoring. No punch in needs, essentially no plugins on cue mixes. Complex sessions but he can bounce that down to rerecord vocals. After getting off DVSC (you have my sympathy) onto Thunderbolt there really is no issue here.

[its2loud]

And neither does *waving hands exasperated* any of this actually matter. There is no problem here, Shawn needs to get going on setting up his Atmos monitoring system and actually tracking with his system, in talking to him today he has more than enough skills to get going with software monitoring and if not then use DADman monitoring. No punch in needs, essentially no plugins on cue mixes. Complex sessions but he can bounce that down to rerecord vocals. After getting off DVSC (you have my sympathy) onto Thunderbolt there really is no issue here.

Amen

[Darryl Ramm]

And to try to wrap up the question about Logic Pro's reported latency.

Originally Posted by shawnhonsberger

...while Logic Pro's measurement is .9ms at 96k with 32 sample buffer.

Logic Pro is not *measuring* anything here, it's just using the latency values reported by the driver and converting them from samples to ms.

And are you sure this was 96kHz? The Project Settings sample rate had not somehow got set to say 192kHz?

It makes sense that Logic's is half 1.8ms at .9ms,

Uh I'm not sure it makes sense. Logic Pro is not performing magic and able to halve RTL latencies. The minimum latency though any DAW *is* the RTL you have been measuring.

Logic Pro has lower possible latency than Pro Tools became it allows for a smaller minimum HW buffer size than Pro Tools does. Be very careful comparing what Logic Pro reports as the "Resulting Latency" values in the Settings>Audio panel since you can't also see the project sample rate in that panel and it is very easy to make a mistake and be using at a different sample rate than you think you are.

If you make changes like change the input or output devices you seem to also have to click the [Apply] button for the "resulting Latency" values shown to update. Yet other changes on this page like changing the I/O Buffer Size cause that value to update without clicking [Apply] (Logic Pro has more than a few sloppy UI things).

It's not hard to make mistakes here at because of these behaviors.

and it's clearly getting that from the driver's reported latency of 90 samples at a 32 sample buffer.

No, again it's not. The Roundtrip latency should simply be the same as the RTL Latency that RTL Utility reports from the driver at the same settings. (it makes no difference that the actual RTL latency is different, Logic Pro is relying on what the driver tells it and will blindly repeat that here as a ms time values). The only place Logic Pro measures any actual latency is in it's ping function in I/O inserts... where it reports the difference between the driver reported latency and the actual latency it measures.

When we talked about the Logic reported Roundtrip Latency today I thought I had measured all these for some of my RME interfaces, but I was missing seeing them in the measurement spreadsheet... they were staring me in the face. They are the "Session Roundtrip (samples)" and "Session Output (samples)" values that are converted from what Logic Pro reports in the Settings>Audio panel but converted from ms to samples, and because of the low resolution ms values the number of samples differ slightly from the accurate driver reported RTL values but well within the implied precision.

https://docs.google.com/spreadsheets...it?usp=sharing

I just repeated some of those measurements and got the same results.

I have never noticed Logic Pro produce wacky numbers there, except where I was confused myself as mentioned above. Maybe you can try carefully reproducing similar measurements for your setup.

[shawnhonsberger]

Thank you, Everyone! This community rocks!!

Thanks, Darryl! I appreciate it! Correct, the settings for the session were set to 96k in Logic, with the 32 sample buffer applied for the .9ms "round trip latency" reported by Logic. Great, I'll try to repeat those tests on my setup. Thank you!

[musiczebra79]

Just got a MTRX II with tb3 card ,also have an avid carbon, and I am missing having the dsp chips, want to upgrade ,but I am worried that will releasing a new hdx card soon? thoughts? jz

[creativecontrol]

No, there isn't an imminent HDX card replacement. If you need dedicated DSP and super low latency with your MTRX II interface, HDX is it.

best,


Jeff