Metric Halo mkiv release

I've looked and I am not seeing anywhere that UADx is 118 samples. Where are you seeing that?

In Cubase I'm seeing a bunch of UADx plugins with 86 samples of latency, but not 118.  Regardless, that's still more than the 55 samples that most of the UAD-2 DSP plugins have, so that's an interesting difference.

wink wink...

Fair enuff, if uad2 and x, null, can they be different code but sonically identical?

Something doesn’t add up, your processor would smoke the shark chip speed?

So, your sampling data implies the way uad2 and x run is different with 2 being more efficient: seems very counterintuitive?

Where are your uadx authorities: cloud, usb? Once authorities are set is there any handshaking ( authority location and ilok mgr and or ua connect ), continuously occurring when uadx are instantiated ?

Interesting, that makes sense. Of course, never any mention from ua of increased sampling amounts/time.

I completely get you!

The guitar plugins use minimum or mixed phase filters or linear phase for filters that are cheaper to compute. They could also use linear phase, half band filters and tell you to run them at 48 kHz or higher if you want to avoid audible aliasing. Many manufacturers and developers do this and don’t even tell you, trusting that you cannot hear the very slight aliasing at the top wif of the audible band at 44.1 kHz, not that there’s anything there but noise and imd in brickwalled commercial recordings.

The guitar plugins programmed by Ray Dratwa have fairly low latency linear phase filters and sound fine. The softube ones are even lower and newer plugins much more complex than the uad2 ports.

Ok, so to circle back on the MHLink latency thing...



I'm not sure what is or isn't being included in those numbers above, but they don't seem to match what I get when I add up ALL the various sources of latency. Forgetting about the other sample rates and buffers for the moment, here is what I get when I add up the latency for a 96k sample rate and a 32 sample buffer, using the new MKIV low latency converter setting (18 samples RTL), based on the available documentation coming directly from the Metric Halo website.

9 samples (=18/2), 0.09375 ms, AD converter
1 ms, MHLink input safety buffer
32 samples, 0.33333 ms, DAW input buffer
32 samples, 0.33333 ms, DAW output buffer
1 ms, MHLink output safety buffer
9 samples (=18/2), 0.09375 ms, DA converter

2.85417 (~2.9) ms total RTL

If I drop the MHLink input and output safety buffers each to 0.6 ms, that then drops the total RTL to 2.05417 (~2.1) ms. In both cases though, neither of these values match the 2.3 ms value that you provided for 96k/32. Can you provide any more info on why this discrepancy might exist?


In any case, if I can theoretically get the latency down to ~2.1 ms at a 96k sample rate and 32 sample buffer (using the new MKIV low latency converter setting and MHLink safety buffers of 0.6 ms), that's only 1 ms slower than what I'm able to get with the Apollo onboard DSP RTL at 96k (1.1 ms).

Which then brings me to the next question which is, can I reliably use MHLink at these settings with a full song going in an overdub scenario? Prior to investigating dual buffer DAWs, my first thoughts on this would have been that NO, I would not be able to maintain ~2.1 ms of latency in an overdub scenario. However, with dual buffer capability in Cubase (and other DAWs like Logic and S1), I'm kind of wondering if MHLink won't actually be just fine for my needs? It may not be the 1.1 ms I get with the Apollo DSP in Console, but 2.1 ms is still pretty fast.

I may not be giving up on the idea of going with Metric Halo just yet. I at least am going to keep thinking about this, unless someone can poke some more holes in what I've said above?

Yeah, if a 128 sample buffer is the lowest you can go in any scenario, including a dual buffer DAW scenario, then, yeah, that might nix it, as a 128 sample buffer at 96k nets 4.05 ms when using the 0.6 ms MHLink safety buffer and 4.85 ms when using the 1.0 ms MHLink safety buffer.  Those are too much latency, as far as I'm concerned.  I'd like it down around 2 ms RTL, and certainly no more than about 3 ms RTL, considering that any plugins you might monitor thru will add more latency on top of that.  Even at 96k and a low buffer (32 or 64), you can still get up to 5 ms in a hurry, once you add a few plugins to monitor thru.

That said, I do have a Mac Studio, so my computer does have a good amount of available CPU to work with, and I'm gonna make the move to Cubase, which does have dual buffers, so I'm wondering if I'd be able to make this work after all?  I've already added up all of the various contributions of latency to see what the total would be for various scenarios, and the total latency would, I think, be okay if I can run the DAW buffer at 32 and the MHLink safety buffer at 0.6 ms, which nets a RTL of ~2.1.  It might even work with either the DAW buffer set to 64 (and MHLink safety buffer at 0.6) or the MHLink safety buffer set to 1.0 (and DAW buffer set at 32), as the RTL in both of those scenarios are under 3 ms (2.72 ms and 2.85 ms, respectively).  It would really just come down to whether or not the CPU on my Mac Studio could reliably handle it.

Anyway, yes it would be great if somebody here in this thread could take a real world RTL measurement with Oblique.

I doubt it but only real measurements from Oblique's RTL Utility will put this to rest.

This is actually a bit more complicated but BJ admits they intentionally underreport latency to the DAW to allow users to manually compensate the offsets since some DAW's don't allow for negative compensation.

He explains here: gearspace.com/board/showpost.php?p=16853694&postcount=7287

FYI, here are some measured RTL values, using MHLink (1ms input and 1ms output safety buffers):


@ 48k 128 samples - 7.75ms
@ 48k 64 samples - 5.083ms
@ 48k 32 samples - 3.75ms

@ 96k 128 samples - 4.885ms
@ 96k 64 samples - 3.552ms
@ 96k 32 samples - 2.885ms


gearspace.com/board/showpost.php?p=17232445&postcount=8195

So, lowering the MHLink safety buffers to 0.6 ms or something would get the RTL even lower, down to around ~2 ms. The question still remains on whether or not your CPU can reliably handle that latency in a late stage overdub scenario. This is where my cautious optimism on the dual buffer DAW concept comes in. Either way, at least we're getting somewhere on what is theoretically possible.

Me too. I have the exact same thoughts. I would be okay with 2 ms RTL (I already work at 96k anyway, and the Apollo isn't much faster at 1.1 ms @96k), as long as Cubase could handle the CPU for that on a late stage overdub. But that's the whole point of dual buffers, right?. Also, I'm not sure about S1, but I think Cubase is supposed to be one of the more efficient DAWs out there, other than maybe Reaper, at spreading around the load to ALL available cores.

I tell you, I'm getting close to just pulling the trigger on a Lio while they're still on sale, and just trying it out for myself. If it ends up working out, I'd have to figure out what my next moves are, but I guess I'd sell one or both of my Apollo x16s, and maybe also my 2192, and use the funds to pick up whatever other conversion I need. I think I would be using an Edge Card in the Lio to use for MADI connections to whatever other converters I might get. I'd want the Lio to be the single point hub for everything. Those Edge cards are such a cool idea, and MH interfaces, in general, just have SO much going for them.