2 MTRX Studio - Which version of PT needed?

[its2loud]

What i like about the MTRX ST is how tightly it integrates with PT, especially being able to control channel Arming and Input monitoring directly in PT

. Wait! Huh? What do you mean by this? You don't need MTRX Studio to do this? Are you talking about Eucon capability here?

[Darryl Ramm]

Originally Posted by patmaki

Thank-you for the inputs. Using TB3 btwn Mac and MTRX ST and would like to avoid HDX/Digilink path if at all possible. I don't use plugins during tracking, but do track large sessions (hence needing 32 AD/DA). I also have headphone cue's fed directly from large format console, so the performers have real-time monitoring (the old skool way! (-. But latency is a consideration during mixing where i employ a fair bit of outboard gear. i'm fine with dealing with this on the MTRX ST, but the unknown is getting the right addition AD/DA and not running into issues between it and the MTRX Studio. Lot's to consider! (-;

Again, the cleanest, safest, but most expensive option is MTRX II, or maybe something like a Lynx Aurora (n) and test out the insert latency for any issues or other interfaces like the RME options.

I do not follow the other post comment about integration with Pro Tools track arm/input monitoring. These are really DAD/NTP boxes, with the MTRX Studio being a more custom design for Avid I just don't follow what integration you are talking about, and on the UAD side if the UAD Console was not being used it should be fairly out of the way. Other good third party interfaces should be able to work just as well for what you are discussing.

Or keeping your MTRX Studio, you can add up 8 IO to it via ADAT at 96kHz but regardless of the ADAT boxes used will almost certainly have HW insert latency differences there that ASC will not automatically correct, it is not hard to manually correct that, just takes making a measurement and setting a value. But that only gives you 24x24 IO.

ADAT will give you a lot less latency than Dante, but presumably you can link two MTRX Studio together via Dante and use as expanded IO including for HW inserts. I would expect significant need to correct ADC latency here. But more of a PITA to correct input latency, and I suspect that would be needed while tracking. But I have no direct experience with two MTRX Studio used like tgat. If you can test all carefully then maybe get your hands on another ones to test.

Or back to aggregate IO with two MTRX Studio, that should have clean input and hw insert/latency behavior but you could be stuck on your own with any aggregation caused instability.

There are far too many latency and ADC related issues and bugs in Pro Tools, including with H/W inserts. Many of these can be worked around/corrected with some effort, but you are more likely to face those when using different interfaces/interface connections.

If you really want to do this with two MTRX Studio then maybe start by trying two in software aggregates, things will be helped by you being able to track at large HW buffer size, if that does not work, then two connected via DADman/Dante, and they have problems then find a Thunderbolt HDN card and use that. But would depend on how much you can test all this carefully so you reduce the risk of having problems in front of clients.

[patmaki]

Originally Posted by Darryl Ramm

Lots of good info there but Digilink licenses are no longer a thing and have not been required with current versions of Pro Tools for some years now.

---

Since the OP is asking how to get 32x32 physical I/O with these systems and Pro Tools Studio, the answer there depends on exactly what you want to do. Be careful of getting stuck with complexity with hardware routing/monitoring and introducing latency differences, including if you want to use these boxes with hardware inserts.

You could span two systems systems together with say Dante and DADman (I'd not) but again depends on what you want to do this for, as you'll see latency there over Dante. You could use macOS aggregate I/O and two MTRX studio connected to a Mac via thunderbolt. But if there are problems there with aggregation you'll likely on your own. And at the point of purchasing two MTRX studios you are maybe just better off buying a MTRX II and adding $$$ preamp/line modules, or maybe looking for alternative options like a Lynx Aurora (n) 32x32 with Thunderbolt card (caution there on the number of folks who seem to have hardware insert/ADC latency issues with the Lynx Aurora (n)). Or since I'm an RME fan boi I'd consider a MADI card set/interface and a M32 Pro AD and M32 Pro DA. Prices for some of these very nice boxes might make you reconsider purchasing Pro Tools Ultimate and going with used HD I/O.

But with HDN being past end of sale life and the problems that Avid has with HD Driver support I'd personally be moving away from Digilink unless I really needed HDX/DSP for tracking.

Great info here, thanks! So as mentioned to Jeff, I don't use plugins during tracking but do use hardware inserts during mixing so your comment about "latency differences" is something I'll investigate further. I considered going the RME route, but it seemed that the software wouldn't be as tightly integrated with PT (as it is with MTRX ST and DADMan)....realizing I could be wrong on this. Ultimately, i'd love to have the additional 16 AD/DA I/O integrate seamlessly (either plugging into the Mac or the MTRX ST) and control all 32 channels via DADMan (with no differences in latency)....ok to buy PT ultimate if needed. Ready to sell the HD I/O as i don't want to go the digilink route. This fussy path i'm seeking seems like it may be too tall of an order at the moment and accepting this may not be possible.

[Darryl Ramm]

I've written about H/W insert latency issues/how to work with H/W insert latency etc. many times but none of the individual posts I can find are great to link to. So I'll savor a can of beer while I write this...

Pro Tools (when you enable ADC) with a CoreAudio interface will attempt to correct for the H/W insert latency (IO buffer, ADC/DAC conversion and some other overhead) but it relies on the latency data reported by the interface driver. In most situations with a simple interface (e.g. all the I/O the same type) this will be the correct data and the ADC will align things correctly.

If you use an interface that has multiple different types of I/O connected to it things don't work so simply. For example ADAT connections off the interface will often have lower actual latency (because there is no ADC/DAC involved) but Pro Tools only looks at what seems to be the latency of the initial input and output ports on the device and assumes they all have the same latency. So insert pairs that are actually lower latency will be shifted back in negative time, and actually lead the signal feeding the insert... because Pro Tools applies too much latency correction or shifted to positive time if the actual latency of the insert is more than the ADC correction. You correct these errors by carefully measuring the offset error, that can be done by recording a click to an audio track, playing that thought an HW insert pair just using a straight though cable, and recording the output of the track with the insert on it to another track. Measuring the difference between the same click signal on each audio track clicks, measure between matching zero crossings on the timeline, you should be able to measure to within one sample accuracy. Now apply that measurement to the +/- ADC field for the track with the insert on it, multiple that value for each insert on the track if needed, you need to manually add those values when you enable inserts, or of the latency is higher than the driver reports you can use the H/W insert delay settings in I/O setups to correct here, but you can't use that to correct ADC over-correction and I just find it easier to work in samples in the ADC +/- field. And for many setups where ADC is not just working all you need is one measurement, (at the sample rate and H/W buffer size you are working at), and you can use that on all inserts connected to the same type of I/O poets, e.g. ADAT or Madi to a remote box.

CoreAudio interface drivers are perfectly capable of reporting different latencies for different I/O ports (or more technically accurate CoreAudio streams). But that's typically ignored by DAWs, not just Pro Tools. But most modern DAWs provide an easy way of ignoring all this and just have a ping function to measure the actual H/W inserts latency. Pro Tools just does not have this, just such an embarrassing deficit compared to other DAWs.

---

When Pro Tools with a CoreAudio interface records audio from an input it automatically corrects for latency, regardless of ADC being enabled or not. But here again it takes the latency info that the driver provides, but with the same limits as above, if you have different types of I/O ports on an interface Pro Tools will use the first port latency numbers reported by the driver. So you can find situations where the recorded tracks are out of time and that might require manual adjustment, maybe modifying ADC +/-, sliding around content, or using a plugin like Eventide Precision Time Align. If mixing up Dante and the physical I/O on a MTRX Studio I expect you to see significant input timing errors, but again they are correctable.

And throw in a few occasional bugs which can complicate things more, but you should be able to get stuff working in almost every situation, it just takes some effort... which may or may not be a PITA depending on how busy you are and how many inserts or different types of inputs etc. you are using. How much you are willing to pay to avoid hassles is the question, again a MTRX II and Thunderbolt should eliminate issues here, but the >$20k price makes an Aurora Lynx (n) 32x32 look damn attractive. Digilink will get you the I/O ports, but you may face latency/H/W insert timing issues there as well but with different causes (like you I'd personally avoid Digilink).

[patmaki]

Originally Posted by Darryl Ramm

I've written about H/W insert latency issues/how to work with H/W insert latency etc. many times but none of the individual posts I can find are great to link to. So I'll savor a can of beer while I write this...

Very good foundational info on latency in PT here! Thank you for this! What do you think about connecting a Ferrofsh A32 pro Dante? Been reading the device manual and Dante controller instructions and watch some videos, but can't find any comments from people who are extending an interface like MTRX Studio which is Dante capable using a Dante enabled AD/DA converter like the A32pro.

[patmaki]

Quick update...., to recap, my goal was to add at least 16 AD/DA to the MTRX ST thunderbolt at 96khz while not having to repurchase/upgrade to PT Ultimate from PT Studio and am pleased to report that I found a setup that is working so far. ended up adding a Ferrofish A32P to the MTRX ST using Dante. Ran a tracking session over the weekend and the setup is working and sounding wonderful so far. Was a bit of a learning curve setting up Dante environment. Ran lots of tests but haven't tried using hardware inserts yet....so am interested to test that.out.

[Darryl Ramm]

Great you got this going.

I'd love to know what RTL latency you measure for the Ferrofish over Dante (samples at a sample rate). You'll likely need to make that measurement anyhow as you set up your hardware inserts and make any latency adjustments.

Since you are running CoreAudio a simple way to make measurements is with RTL Utility. https://oblique-audio.com/rtl-utility.php

Both the driver reported and actual measured RTL latencies would be interesting to see.

[patmaki]

Originally Posted by Darryl Ramm

Great you got this going.

I'd love to know what RTL latency you measure for the Ferrofish over Dante (samples at a sample rate). You'll likely need to make that measurement anyhow as you set up your hardware inserts and make any latency adjustments.

Since you are running CoreAudio a simple way to make measurements is with RTL Utility. https://oblique-audio.com/rtl-utility.php

Both the driver reported and actual measured RTL latencies would be interesting to see.

Ran this test this morning. Did it the old fashioned way, then tried RTL software. However, with RTL software, got the error "Couldn't reliably detect signal. Check connections and channel gains". I had it on 16 in and out of MTRX ST which was the same as was used manually, so not sure what i'm doing wrong. As far as the the method doing it the old fashioned way, I sent a kick signal through the distressor in bypass. There were no plugins on the source channel. In the first test track, i sent the kick signal out of CH 16 on the MTRX ST and back into CH 16 of the MTRX ST. This had 5.85 ms RTL. On the second test track I sent out of CH 1 and back into the CH 1 of the A32Pro. This had a 6.19ms RTL. So difference of .34ms.
I did have the HW buffer size set at 512 samples. Not sure does this need to be set a certain way when doing an RTL test?
Also, Delay Compensation was also turned on.
If you have any comments about this testing methodology, please let me know. Happy to restest if there's a flaw somewhere in this test. Attached is a screenshot.

[Darryl Ramm]

Thanks for doing this.

Originally Posted by patmaki

Ran this test this morning. Did it the old fashioned way, then tried RTL software. However, with RTL software, got the error "Couldn't reliably detect signal. Check connections and channel gains". I had it on 16 in and out of MTRX ST which was the same as was used manually, so not sure what i'm doing wrong.

Something is wrong here if RTL Utility does not work. This is *the* tool used by so many folks including manufacturers. A common mistake is to not set the Output and Input device to the same. Unlike Pro Tools RTL Utility can use different input and output devices and any (matched or non-matched) ports on those devices. Once you have both the same devices selected then make sure the output and input channels on those devices are correct. Sample rate and buffer size **set in the RTL Utility UI** are correct.

Using RTL Utility also removes any chance of errors possible if using Pro Tools, including running into bugs in Pro Tools. I would work out what is happening with RTL Utility. Does the Test Button work? Do you see meters on the interface? If you connect up monitors do you hear the test tone? etc.

Although I would hope it should be OK I would make sure Pro Tools and other apps are not using the interface when you run the RTL Utility tests.

As far as the the method doing it the old fashioned way, I sent a kick signal through the distressor in bypass. There were no plugins on the source channel. In the first test track, i sent the kick signal out of CH 16 on the MTRX ST and back into CH 16 of the MTRX ST. This had 5.85 ms RTL. On the second test track I sent out of CH 1 and back into the CH 1 of the A32Pro. This had a 6.19ms RTL. So difference of .34ms.
I did have the HW buffer size set at 512 samples. Not sure does this need to be set a certain way when doing an RTL test?
Also, Delay Compensation was also turned on.
If you have any comments about this testing methodology, please let me know. Happy to restest if there's a flaw somewhere in this test. Attached is a screenshot.

So again, I'd get RTL Utility working since you should check any other measurements with that anyhow. And the reported RTL (i.e. the sum of what the driver tells the software the interface input and output latencies are) there is as interesting as the measured RTL. After all, the issue that folks typically run into is how much do the reported and measured latencies disagree.

If I am following what you are doing, you are not doing your Pro Tools test as an insert test but rather going out and back in on two tracks, in this case enabling ADC should correct for output latency that was not otherwise corrected (but hardware insert latency correction, both the input and output part, correction requires ADC to be on). And so doing what you are doing with an ideal interface with ADC turned on you should see zero samples of latency for the interface since that latency is all corrected in this test. That you don't see that seems to point to a problem here... but it is kinda surprising/hard to believe that the MTRX Studio main analog I/O would have such a problem. Pro Tools likely treats all interfaces I/O as having the same latency (that of the analog input and output I/O ports) and I'd expect the Dante connected I/O to have more latency that was not corrected and so appears to lag on the timeline.

Yes H/W buffer size have a direct impact on latency. All the H/W buffer does is buffer I/O from the DAW/application to the outside physical world so changing the H/W buffer size always affects that (well for native systems, not if you have HDX). But the driver includes the contribution from the latency due to the H/W buffer size so applications can correct for this. If you change the sample rate or H/W buffer size, the driver lets the app/DAW know stuff has changed and it can ask for the new latency values.

What sample rate are you measuring at? It's better to just keep all work/measurements in samples.

[patmaki]

Originally Posted by Darryl Ramm

Thanks for doing this.



Something is wrong here if RTL Utility does not work. This is *the* tool used by so many folks including manufacturers. A common mistake is to not set the Output and Input device to the same. Unlike Pro Tools RTL Utility can use different input and output devices and any (matched or non-matched) ports on those devices. Once you have both the same devices selected then make sure the output and input channels on those devices are correct. Sample rate and buffer size **set in the RTL Utility UI** are correct.

Using RTL Utility also removes any chance of errors possible if using Pro Tools, including running into bugs in Pro Tools. I would work out what is happening with RTL Utility. Does the Test Button work? Do you see meters on the interface? If you connect up monitors do you hear the test tone? etc.

Although I would hope it should be OK I would make sure Pro Tools and other apps are not using the interface when you run the RTL Utility tests.



So again, I'd get RTL Utility working since you should check any other measurements with that anyhow. And the reported RTL (i.e. the sum of what the driver tells the software the interface input and output latencies are) there is as interesting as the measured RTL. After all, the issue that folks typically run into is how much do the reported and measured latencies disagree.

Ok, I'm determined to figure out the RTL issue now (-;. Both IP and OP are set for MTRX Studio CH 16. When I hit "TEST" everything seems to work fine (Distressor lights up, CH 16 IP and OP meters on actual MTRX ST unit light up). However, no sound from monitors and the monitor meters don't light up in DADMan. This is baffling since I was mixing with HW inserts just fine last night with the same setup. So that made me wonder if it's an issue with how I have DADMan configured. Hmmm, stumped for now. Some pics are attached.