2 MTRX Studio - Which version of PT needed?

[Darryl Ramm]

You won't hear anything in the monitors/see activity in the monitor section with RTL Utility unless you set up a custom monitoring route in DADman. I had meant hear something if you physically attach a powered monitor/headphone amp to the same output you are sending the ping out of with RTL Utility. But if you can see the output meters move move that's not needed.

I can't see anything obvious jumping out but there is lots of DADman not in those screenshots. I would spend time looking all over DADman including the I/O gain levels. And use the DADman meters to look at the output and input levels and they should match the level shown in RTL Utility.

It would be handy if RTL Utility also had a continuous signal generator to help tracking things down.. and one of the things I also dream about is a utility that speaks the interface/IO port name/numbers out the ports and overlays that speech on any input signal .

I'd normally take the Distressor physically out of the picture and use a straight through cable but understand that may not be easy depending on what cabling/patch panels you have. And if you are seeing input on the other side of the Distressor then maybe start by checking the levels in DADman.

I would expect you could also try to get RTL Utility to work with Thunderbolt to Thunderbolt Loopback in DADman just to at least see it works at all.

[patmaki]

Originally Posted by Darryl Ramm

You won't hear anything in the monitors/see activity in the monitor section with RTL Utility unless you set up a custom monitoring route in DADman. I had meant hear something if you physically attach a powered monitor/headphone amp to the same output you are sending the ping out of with RTL Utility. But if you can see the output meters move move that's not needed.

I can't see anything obvious jumping out but there is lots of DADman not in those screenshots. I would spend time looking all over DADman including the I/O gain levels. And use the DADman meters to look at the output and input levels and they should match the level shown in RTL Utility.

Short vid: (https://drive.google.com/file/d/1aoD...ew?usp=sharing). Both I and O levels in DADMan are 18dbu, but I don't see a place in RTL to verify these numbers.

Originally Posted by Darryl Ramm

It would be handy if RTL Utility also had a continuous signal generator to help tracking things down.. and one of the things I also dream about is a utility that speaks the interface/IO port name/numbers out the ports and overlays that speech on any input signal .

Sounds like a great product idea! I'd buy it (-;

Originally Posted by Darryl Ramm

I'd normally take the Distressor physically out of the picture and use a straight through cable but understand that may not be easy depending on what cabling/patch panels you have. And if you are seeing input on the other side of the Distressor then maybe start by checking the levels in DADman.

This is easy as everything's tied into patchbays. Re-ran tests...same result.

Originally Posted by Darryl Ramm

I would expect you could also try to get RTL Utility to work with Thunderbolt to Thunderbolt Loopback in DADman just to at least see it works at all.

See vid: https://drive.google.com/file/d/1doc...ew?usp=sharing. Attempted, but not sure this is right but it is showing Ch 1 I and O with signal in DADMan.

[Darryl Ramm]

Originally Posted by patmaki

Short vid: (https://drive.google.com/file/d/1aoD...ew?usp=sharing). Both I and O levels in DADMan are 18dbu, but I don't see a place in RTL to verify these numbers.

The place in RTL Utility to verify those numbers are when you actually make a measurement... in the "Return Level" field and you are getting nothing there. I'm not sure what the cut off is but IIRC it's very low so there really looks like nothing at all is getting back to RTL Utility.

See vid: https://drive.google.com/file/d/1doc...ew?usp=sharing. Attempted, but not sure this is right but it is showing Ch 1 I and O with signal in DADMan.

I don't have a DADman system here, have only played with them briefly but my suspicion is you might be causing problems with how you are monitoring stuff, and it's the monitoring section I really have not played with, it might be worth completely disabling monitoring in DADman and see what happens.

Or maybe other users here have a better idea.

[patmaki]

Originally Posted by Darryl Ramm

The place in RTL Utility to verify those numbers are when you actually make a measurement... in the "Return Level" field and you are getting nothing there. I'm not sure what the cut off is but IIRC it's very low so there really looks like nothing at all is getting back to RTL Utility.



I don't have a DADman system here, have only played with them briefly but my suspicion is you might be causing problems with how you are monitoring stuff, and it's the monitoring section I really have not played with, it might be worth completely disabling monitoring in DADman and see what happens.

Or maybe other users here have a better idea.

Hi Darryl, after some back and forth with Andrew at Oblique Software (He's provides very good support, thanks Andrew), we got RTL working and I'm now a customer. RTL was also helpful in showing me the return levels which helped to get the gain levels the same between the two devices. That alone was worth it!
Attached are the results between the two devices. The RTL numbers seem to be about double what I was getting in my manual testing in PT.
A couple conditions to be aware of going into the test were:

1. I have to choose a device latency value for both devices in Dante Controller. I selected the smallest value for both (.25ms) (screenshot attached)
2. In RTL, one can select the "Actual buffer size" and i had this arbitrarily set to 512 samples. Guessing this is why these results are about that many samples larger than the manual test?

Any guidance you can provide on how to interpret or possibly re-run the test to get the best A/B conditions is appreciated.

Thx,
Pat

[Darryl Ramm]

Great!

I am in touch with Andrew as well. Looks like he has fixed the issues he had with microphone/audio input privileges in the recent builds, but I am yet to play with that myself… not at a computer now.

Thanks for persisting here, just wanted to also make you aware of this other thread https://duc.avid.com/showthread.php?t=425811&page=4

The buffer size in the RTL Utility you select is the same critter as the HW buffer size you choose in Pro Tools, it is what both programs ask the driver to set its buffer size to. Drivers may add additional latency to that beyond just the actual hardware converter conversion latency, and software applications may also add additional latency (Pro Tools adding additional latency (and sometimes screwing that up) when ignore errors is set in the playback engine settings is one example). But when doing things like say measuring an insert latency in Pro Tools by hand vs using RTL Utility you should be within one sample of agreement. The cause for large errors is often having ADC enabled and then you are measuring relative to the ADC (incorrectly) corrected latency not the absolute latency. RTL Utility is always just measuring the absolute RTL latency, it also reports the latency the driver provides, but does not apply that correction.

I will get back to you with better comments and I may need to get both of you another tool to report the different latency components reported by the driver. edit: and nope no additional tools are needed, RTL Utility does report internal conversion, safety and stream latency components, you just need to choose to display them in the report log, thanks to Andrew for pointing these out to me, I had totally missed that, and I clearly did not read his past release notes or the documentation ¯\_(ツ)_/¯