I’m surprised RME doesn’t have a PCIe card with MADI that they could pair up with one of their MADI breakout boxes to create a UFX type setup with super low latency. Are there technical considerations that make that impossible or impractical? Seems on the surface like it would be a great way to get ultra low latencies, great performance, and large IO counts in a rackmountable package.

They'll do. They even got two models.

https://www.rme-usa.com/hdspe-madi-fx.html

https://www.rme-usa.com/hdspe-madi.html

If I were building a new project studio from the ground up, this is what I'd get, along with a lunchbox 500 series.

I swear I was on RME's site recently looking for a MADI PCIe plus breakout good solution and I must have missed them. If money were no object, that seems like it would be the way to go.

I have a lynx Aurora/AES16e, if I was to do it again I'd still get the Aurora but I'd get an
RME HDSPe AES. I was able to find a LT-MADI LSlot interface for my Aurora so now instead
of an AES card I would rather get an RME HDSPe MADI card since MADI works with alot
of network audio devices.

I was thinking about building an RME HDSPe RAYDAT rig, if you order from Thomann the prices are do-able. It's on the very long list of things that seem like good buys.

I think this belongs here without being a reply to anyone's particular post:

With the Midas M32 in my studio and its predecessor, the Behringer X32, I have collected a data set of every connectivity option for those boxes, and have run the Oblique RTL tool against them in both Win10 and macOS.

As for what's missing in the attached charts, I never bought a PCIe Dante card, so there's only Dante Virtual Soundcard (DVS) connected to the DN32-MADI adapter of the M32. Also missing from the data is the Lynx AES16e-50 on macOS. The Lynx is a unique PCIe card that does AES3 and AES50, which is the digital snake protocol for the X/M32. I can't remember if I ever tested it on macOS.

The LoopBk column is the direct ADAT-out to ADAT-in of the RME HDSP 9652 card. The M32 has 0.917ms of round-trip delay in it according to the Oblique RTL tool. That works out to just a touch over 44 samples. I found that adding 45 samples in the DAWs makes all recording alignment spot-on.

Another interesting result is that the RME HDSP 9652 loopback latency measures exactly the same in an ASRock X570 Creator 3950X machine and a lowly HP Z220 that has an i5-3470; 4-core 3.2GHz no HyperThreading.

The interfaces to the mixer are: RME HDSP 9652, RME ExpressCard MADI, Lynx AES16e-50, Klark-Teknik DN9630 AES50-to-USB, X-USB 2.0, and Dante Virtual Soundcard.

Hi, has anyone done any testing on the new Tascam interfaces?


TASCAM US-4x4HR USB

https://tascam.com/us/product/us-4x4hr/top

https://tascam.com/us/product/us-4x4hr/spec


Any thoughts on driver quality e.t.c.?

Do the LT-MADI cards work in the newer Aurora (n) series?

Don't know, the L-slots that work in the n also work in the old Auroras. Don't know why they
discontinued the L-slot MADI unless it wasn't selling I'd say ask Paul but every time I've talked
to him I walk away more bewildered than to begin with. Get the feeling he's high or some other
problem. Shutting down the forum was pretty stupid.
If I could afford it ans was to make a major change, Id sell the Aurora and get an
RME M-1610 Pro and an RME HDSPe MADI card

I'd bet money that they aren't anything special. I had a couple and they aren't any good. (Previous models)

This thread is kind of an unwieldy beast.

Does anyone know what input latency number is for the UA Apollo 8x/8xp is? Not using their console software, just straight up into Pro Tools at a normal buffer (say 64) size ?

I suspect you might be right. I am inclined to just go for broke and invest in a RME. I figure it will last me a long time.

It really depends on what the input latency compensation is set to.

Here were my figures for round-trip-latency:

Compensation == OFF:


Compensation == SHORT:


Compensation == MEDIUM:


Compensation == MEDIUM-LONG:


Compensation == LONG:

Thanks. What do you mean by "input latency compensation"?

So the college I lecture at recently got Apollo 8X in their studio. I wanted to do as it sound like you are thinking - ditch Console and do the cue mixes in PT/ Logic etc. After much stuffing around and a support ticket with UA it seems that with all Apollo's it is not possible to record direct into any DAW without Console running. This does not mean you have to do the cue mixes in console but you do have to have it running.

So guess what? Without console running and at 32 sample buffer RTL in Logic reports sub 3ms, but with console running the RTL is over 5ms. The 3ms is pointless as you can't get signals into the DAW without console running. You can only get sound out.

IMO the lesson here is if you don't want to track with UA plugins DON'T buy Apollo.

It's a hardware setting that you configure inside of Console. Even if you don't use Console for any of your monitoring, it still affects the unit.

Essentially there is no way to run the device *without* Console - Console always connects and controls the hardware, thus introducing latency.

That's feature, you can set in Console preferences.
Essentially quite a lot of UAD DSP effects has a latency due to its processing (like internal oversampling).
You can check individual effects at useful table maintained by Matt over UAD Forums.
https://docs.google.com/spreadsheets...t#gid=50638092

So when you add such effect to some input channel there, it become delayed against other channels.
Then you have a choice, either leave that it as is (like you don't mind to listen to one delayed channel in monitoring), or compensate that.
The only way how to manage the compensation, is to delay everything according to channels with such processing applied. Similarly like latency compensation in DAW works.
You have few fixed steps there.. it adds 100, 200, 300 and 1000 samples of delay.
If processing delay of used effect chains fits into that compensation "window", audio is aligned and phase coherent.

Yes, that's the hardware architecture of those UAD Apollo devices.
Input signals always goes through DSP there, that's its inherent attribute.
The Console controls hardware DSP and I/Os, so naturally if you don't start it, it doesn't initialize and control DSP, so it doesn't pass any input audio.
Playback channels from the driver were always different with its "direct" routing to physical outs, you can also notice that by asymmetric input and output latency figures. Those are reversed to most of other native interfaces, where you have typically larger output latency than input latency.
In case of Apollos, output latency there is comparable, but input latency has added that DSP processing part, so that makes it longer.

However that design decision also makes some sense. When some processing delay on DSP chips running the mixer and printable, in-line Unison effects is inevitable, they've chosen to keep output latency as short as possible. So for example people performing native virtual instruments aren't affected by that.

Michal

Thanks everyone for your very clear answers. That’s a bummer because while I do like UA plugs for mixing, I wouldn’t track through them.

My HD Native / Omni set up gets 82 samples or about .5 ms at a 64 buffer (and is rock solid). I’m not going to give up that performance.

Are there any USB / TB3 interfaces that can match that? RME maybe?

Presonus Quantum and Antelope Audio can match RME performance, but only through Thunderbolt.

I don't understand your post.

82 samples = 0.5ms @ 64 ?

At 96kHz 82 samples is 0.85ms. And RTL is conversion time + (2 X samples)/SR

For HD Native + OMNI RTL for 64 buffer 96kHz was ~2ms when I owned it.

I thought it was kHz/samples?

44.1 / 82 = .537etc

Samples/(Samples/sec) = seconds

(1 Sample)/(44,100 samples/Sec) = 0.000023 sec = 0.23msec

82 Samples/(44.1kHz) = 1.86ms

IME RTL of HD Native is ~ 3.4ms at 44.1kHz 32 buffer and ~2ms for 96kHz 64 buffer

Its the opposite actually.

Samples/KHZ

82/44.1= 1.859ms

82/96 = 0.85ms

ProPower is correct

* Ha, we were posting at the same time :-)

Yes of course! Had it backwards. Haven’t done this in a while. Thanks guys.

So the question is, are there any thunderbolt or USB interfaces that match the performance of a PCIE card? Also, if I put the PCIE card into a thunderbolt enclosure will I get the same performance?

IME - in raw RTL TB has some of the lowest values I have ever seen - always lower than USB2/3. AFAIK there is very little data bus latency on TB and RTL ~= to Conversion time + 2*DAW buffer/SR.

Antelope, Apogee on TB ~0.3ms at 96kHz (using their direct monitoring)
~1.2ms 96kHz/32 buffer through Logic
0.3ms for Apogee with Logic usingApogees Dual Path plugins

AVID i/o (LLM) ~0.45ms 96kHz
~2ms (could be 1.9) 96kHz/64 buffer through DAW

Again - AFAIK PCIe cards can do no better in raw RTL. LL performance though is more driver dependent - so in the spirit of this thread - I believe PCIe is still #1

I thought TB3 was fast which is why I was surprised that the Apollo x with compensation off was more than 3x the rtl of the HD Native / Omni. Is that just poor driver performance?

No, it's design of the unit with in-line DSP, as I wrote in the post above.
Driver performance (efficiency, stability at short buffers) is actually fine.

Michal

Then what’s the point of a “no compensation” option?