Can TB3 be the only connection to the Mac?

[BScout]

Originally Posted by shawnhonsberger

I ask because of the following on the NTP Site: https://ntp-us.com/dad/ax-center/



With a buffer size of 32 samples, the latency is 670 microseconds at 96 kHz. That's .67ms on TB3 according to NTP.

That shouldn't be 2.5ms on Pro Tools, right? Even if I double .67ms, it should be 1.3ms with a 64 sample buffer in Pro Tools.

You are comparing the AX Center to the MTRX Studio.
They are not the same device.
AX Center is built on a different FPGA and includes ThunderCore (which is why it has 256 bi direction on its TB3 vs only 64 bi directional on the MTRX Studio). The AX Center is part of the family of NTP/DAD's next gen devices: Core 256, AX64, MTRX II.

[Darryl Ramm]

Originally Posted by shawnhonsberger

The DAD/NTP site says that the TB3 card is 7/9 samples or 1.7ms with a 32 buffer size, so why is it that Pro Tools only allows 64? Is it adding an extra 32 for CoreAudio even with its own interface? If so, why?

Only allows 64 sample buffer size at what sample rates? Sample rate is all critical here but you don't mention it. And I don't think the math works out here, is the a 1.7ms RTL or one way? Or are these mixing up specs from different sample rates? (it might also be ignoring some additional latency).

Pro Tools is not adding anything here to get a minimum of 64 sample H/W buffer. The H/W buffer size is the H/W buffer size, end of discussion. It's what Pro Tools asks the driver to set the buffer size to via Core Audio, but it is only one component of the latency that the driver will report back.

When asked by Pro Tools the device driver offers up over CoreAudio all the buffer sizes it supports, Pro Tools will ignore H/W buffer sizes below a certain value, as it also can do above a certain value. The exact values Avid decide to cut off at they would have to justify. But they need to trim somewhere, if nothing else at the lower end for customer support reasons. e.g. My RME drivers can do 16 samples, Avid (not being stupid) never exposes that value... doing so would only cause customer support problems and complaints from folks about why it's not working reliably.

As you decrease these fairly small buffer sizes to gain say another 32 sample reduction in latency you potentially cause a very significant decrease in stability, and here I mean stability under load, not just trivial no-load latency benchmarks. DAD like all vendors can quote low latency numbers all they want but until you know what you can get with your sessions it really is not much help. Once you get near buffer sizes like 32 samples the contributions from other components than the buffer size start becoming more significant. Vendors can't keep chasing low latency into a mess of instability, for diminishing absolute returns, and folks who have a super-critical latency need can use hardware monitoring (which OK yes does have a conversion latency and possible a few other samples overhead).

When asked what the interface latency is the driver reports back a set of three latency values that are the contributions from hardware conversion latency, H/W buffer size, and some additional overhead. Important to note that Pro Tools adds additional latency to that if you have ignore errors enabled... (and when it does that may screw up things, so just don't use ignore errors).

The real question is could the system work reliably at 32 sample H/W buffer (I'm guessing you are at 96kHz?) for many users, and has that changed with modern computers and drivers? Hopefully Avid keeps an eye on this an works with DAD on this stuff and would change the lower limits if it was justified. Another wrinkle is these modern DriverKit drivers introduce additional complexity. I'm over the moon happy to see RME Driver Kit drivers working reliable at 64 sample I/O buffers with ~100 I/O and some plugins in the system (and getting that on Sonoma) and I would hope for similar from DAD with their impressive engineering and quality.

What types of workloads have you tested under at 64 sample buffer (at 96kHz?) on what Macs? If users are able to get really stable performance with decent workloads then it's something to maybe push on Avid for lowering the I/O buffer size (or maybe lowering it only for DAD or some interface vendors? Maybe only on Apple Silicon native? etc. ).

---

And while it's important to be careful of fixating on latency, especially no-load latency, it's still interesting stuff technically. I've not seen any serious RTL measurements of a Thunderbolt equipped MTRX or MTRX Studio. And the interesting stuff there for me is to see how it reports latency across it's different transports and if they are accurate and if Pro Tools follows all or ignores some of that latency data (I expect the later, consistent with how it behaves in general, which would affect some configurations using hardware insert performance as well as standard input latency correction, but how much this is, well lets see some numbers...).

One other user here started to try to make some measurements and ran into problems. https://duc.avid.com/showthread.php?t=427318&page=3 I wish I knew what happened there.

Maybe you could grab RTL Utility (https://oblique-audio.com/rtl-utility.php) and make some measurements of your setup. ... it's normally simple to do. If you get stuck or need help ask. And if you want to see details like the different component of latency reported by the driver I can either get you a tool from Apple or one of my tools (I wish RTL Utility would just report those in its log, I need to bug the developers).

Or heck anybody with a MTRX Studio with Thunderbolt who does not need it for a while y'all can ship it to me and I'll crank out a complete set of latency info, and map out any issues/workarounds with I/O latency correction, and hardware inserts

[shawnhonsberger]

Thanks @BScout. That's super helpful. I hadn't thought of that aspect of it before. I guess that I bought the MTRX Studio, and especially the TB3 card with a false understanding or misunderstanding of its actual specs. I think I made the assumption because others on this forum had asserted that the TB3 card from Avid was identical to NTP/DAD in its function and performance.

Thanks @Darryl Ramm. You've given me a lot to think about. I'll need to chew on it all to understand it better, as well as try out a few things and get back to you.. Either way, I also find all of this super interesting and would love to have a full understanding of all the RTL differences at every sample buffer and sample rate between HDX and TB3.

Thank you, all!

[BScout]

Originally Posted by shawnhonsberger

Thanks @BScout. That's super helpful. I hadn't thought of that aspect of it before. I guess that I bought the MTRX Studio, and especially the TB3 card with a false understanding or misunderstanding of its actual specs. I think I made the assumption because others on this forum had asserted that the TB3 card from Avid was identical to NTP/DAD in its function and performance.

The card itself is identical (the TB3 module.)
What it can do is dependent on the processor in the overall hardware (the FPGA.) The more recent units use a different FPGA.

[shawnhonsberger]

Here's what Logic says:
96k with a sample buffer of 32: .9ms round trip
96k with a sample buffer of 64: 1.6ms round trip

DUC won't let me attach images.

[Darryl Ramm]

...and that is doing what exactly? It's a number but what does it mean?

Is it reporting on the RTL time for the first I/O pair? Like many DAWs and ignoring others? These are the analog I/O? Does the reported value change if you map different I/O there to the first I/O ports in Logic with DADman?

The easy(ier?) way to really understand what the interface does is to use RTL Utility. Which is why I keep pointing that out. Then you can map what you measure there that to how the DAW performs or rather often misperforms (once you combine different latency I/O in the same interface box/driver instance).

[BScout]

Originally Posted by shawnhonsberger

Here's what Logic says:
96k with a sample buffer of 32: .9ms round trip
96k with a sample buffer of 64: 1.6ms round trip

As Darryl points out, Logic's "results" mean nothing with modular systems like the MTRX which are variable. It doesn't account for the actual format or conversion times because the driver doesn't know. It's just reporting back what the driver tells Logic and on modular systems like the MTRX, that's less than 1/2 the story. You are only getting the number of TB3 CoreAudio which gets you only one leg of the trip on RTL. It gets you the time to get into the box. But then there's the time of going from the digital matrix of TB3 to output format (and that depends on output -- Dante, ADAT, Analogue all have different numbers and some differ based on sample rate and some don't) which is chosen by the user. Then there'e the input format (also variable) and then hopefully the CoreAudio time of returning back by TB3.

[Darryl Ramm]

Yep. Well the driver could know... it could dynamically update all the I/O latencies depending on the routes but yikes that could get to be a mess... and then even if it does that Pro Tools is not going to handle the data correctly, since it can't do that today for simple interface with multiple different latencies even when the drivers report them properly.

I'm hoping DAD might do something smart here and that is what I was hoping some RTL Utility measurements will show, since at least with RTL Utility unlike Pro Tools or Logic you know the exact input and output pairs it's reporting on. And again the interest is not just in what is the value but is the value reported by the driver correct or not. At least then stuff is understandably and possible to manually correct in the Pro Tools.

Really nobody has a MTRX studio they want to ship me?

[shawnhonsberger]

Okay, thank you both. I'll try out the RTL Utility and get back to you.

As far as Logic is concerned, I think I am sending 12 channels of I/O via TB3 into DADman. It says it is measuring .9ms for RTL input to output, and .5ms from software to output. But I see both your points.

Haha, I wouldn't mind sparing my MTRX Studio if I had a few of them. The one I have took quite a while to get, and then another 9 months for the TB3 card. :)

[Darryl Ramm]

Originally Posted by shawnhonsberger

As far as Logic is concerned, I think I am sending 12 channels of I/O via TB3 into DADman. It says it is measuring .9ms for RTL input to output, and .5ms from software to output. But I see both your points.

12 channels of what I/O? And you are looking at what? Logic Pro>Settings>I/O? Logic Pro is *not* measuring anything there, all it is doing is reporting the latencies that the driver tells it, but for what? Likely just the first pair of I/O it sees. And is the driver even reporting correct info for that?... lets look at the numbers from RTL Utility.

Again with these boxes each I/O port potentially has different latency depending on what you have that Thunderbolt routed to in DADman. And Logic like most DAWs is likely to report the latency for the first I/O on the interface. Knowing what the DAW (often mistakingly) thinks any I/O latency is is only really interesting once you have mapped out the actual and reported I/O latencies with something like RTL Utility.

And if you want to see what the RTL is for an actual pair ah ha you would think you could just pull up an I/O insert in Logic Pro and press [PING] and ta da Logic would measure the actual latency. And you would be *wrong*. The Ping Offset number in Logic Pro is an offset, not an absolute latency, it is relative to the automatically calculated Insert latency from what the driver reports as the input and output latencies. This is just one minor thing about the Logic Pro ping function that could be clearer, but heck at least it has one. And yes with some other tools and basic math you can mumblefart that latency offset back into an absolute latency, or you know.. just use RTL Utility.