Thank you very much!

@@MattHepworth thank you too

Thank you so much!

Thanks so much!

Thank you!

Thank you very much!

That is a HUGE complement! Thank you!

Glad it helped!

Thanks! Glad it helped!

what’d you get?

Thanks!

Thank you!

Hi there. If you're not using your ADAT outs you can indeed use as S/PDIF instead. I use mine for ADAT outs, though. The line outs seem to be the same as the monitor outs. Some good comments there, thank you. I don't fully agree with the last sentence, though. While performance is number one, I definitely like to have the final goal in mind from the start and tend to keep the workflow just like it would be with outboard. For example, a performer performs into the compressor. With UAD there's a comfortable selection of quality good enough I rarely reach for outboard. It's more of a struggle with AAX DSP options, though. They do end up being "comfort" tools more than I'd like.

Thanks for the comment and congrats on the upgrade! That should treat you well. I never had an Alphalink, but people do tend to feel pretty good about their conversion. Sounds like you've got a great setup!

Thanks! Part 2 will be this week. Carbon has a similar color and layout to DAD, but it's solely an AVID design. I've done very little with Carbon on M1 so far, but mostly positive.

I did cram in as much info as possible. ;-)

Good questions. No, the latency is no different on Intel or Apple M series. Also, since DSP is what's being used for monitoring in both situations, the buffer is irrelevant and does not affect anything except CPU load.

Leverage all the tools needed to reach your goals. Carbon is part of that for me.

Thanks!

Thank you! Well, I sold my Carbon, but it had a lot to do with my studio location having to close to get ready to sell the real estate... Apollo with LUNA has come a long way and I'd probably use that exclusively, if I was working on my own material/for myself. There's a lot to be said for the Carbon/HDX/TDM Pro Tools workflow - there's nothing slicker...

​@@MattHepworth thank you for the response. Have you tried RME stuff? I am getting .3 MS latency through total mix fx on my Babyface PRO FS. Nothing can touch it for direct monitoring - including carbon. Obviously latency isn't the entire story as everyone has different requirements but I just thought I'd share my findings with you.

Yes, I have owned a few RME devices and currently use a Digiface USB. I've joked that RME is a driver company that also makes pretty nice interfaces. ;-) TotalMix is excellent. As far as latency goes, the UC series is around 0.7ms through TotalMix, up until the UC III, where that latency was reduced. I assume the Babyface PRO spec you're listing is at 96kHz (though it's theoretically possible it may low enough latency converters that could be at 48kHz)? The downside, of course, is you're not getting the advantage of single window tracking workflow with processing, but I do love the flexibility and low latency of TotalMix.

This was at 48. Using RTL Tool determined BF pro Fs is .16 ms at 96 direct monitoring through Total Mix FX. The UCX 3 only slightly slower. The Babyface Pro FS is really something else. You are correct - great drivers and pretty nice interfaces. Did a comparison of the UFX 3, Pro FS, Merging Horus, and DAD AX 64. DAD via TB3 was king of the hill in terms of RTL. Surprisingly the UFX 3 held its ground in re gen tests compared to the much more expensive convertors. Rme designs have incredibly flat conversion, great headphone amps and fantastic latency. Speaking of latency don’t get me started on native latency over Ethernet based protocols. (One reason I’m cautious about buying carbon) Merging via AVB was unusable RTL wise so we ended up using its MADI into an RME PCI card which gave it respectable RTL numbers. Overall with this configuration the merging was the best interface. I love this talk! Total nerd! Keep in mind when I started recording records in 2004 I bought a protools HD system and spent a decade not even knowing latency or buffer sizes existed… lol. So you can see I’m sensitive to it and always on the look out for the ideal set up.

Thank you!

Thank you! I'll do my best to answer any questions.

I believe it's still the same as when I bought it: perpetual license with 1 year subscription. I believe you need an active subscription to use iLok Cloud.

Yeah, it's easy to get into the same situation as Native latency.

Glad it's helpful!

Most people don't perceive the delay from latency until beyond 10ms, but any source with near zero latency (especially a vocal) produces radical amounts of comb filtering as the latent signal blends with the source. Everyone's tolerance here varies, but people sensitive to it tend to agree that more than 2ms is unpleasant and less than 2ms is much more comfortable to work with. Check out this article for some illustration and simple way to see where you fall in. www.whirlwindusa.com/tech-articles/opening-pandoras-box

Great question! It's only while actually recording that the latency and plugins have to be so carefully balanced.

That’s very helpful!! Thank you 🙏

I do. MAYBE okay for doing VIs, but not much else.

Glad I was able to help with your decision either way!

Should be as easy as connecting the BAE into the B2 and B2 to S/PDIF in on Apollo. In Console you'll have a channel for that input for monitoring. Apollo clock set to S/PDIF.

@@MattHepworth Thanks Matt that's the way I have it set up but there's no signal coming into the Apollo console input ch. maybe keep everything as is and also come out of the B2 AES into the Apollo 6x line input 3?🤔Thanks so much for your time...👍

Note: The B2 is showing the BAE micpre 1073 signal coming in at a good level

The AES needs to be connected to a digital input. It can't work into one of the mic pres (and be extra careful you don't enable phantom and fry your Burl). You'll need an AES/EBU to S/PDIF adapter if the B2 doesn't have S/PDIF out.

​@@MattHepworth Thanks for saving my Burl I will scratch the AES idea ...lol The B2 does have a RCA S/PDIF out. and a TOS out sweetwater sent me a OPM303 3' Premium Optical Cable to come out of the B2 TOS into the Apollo ADAT A/MUX IN 1 Thanks again... GREAT KZfaq CHANNEL!👍😎

I'll reply in more depth when I can, but one way I do it is I do a wet/dry of the channel as a group in PT and mute the dry channel in both Console and PT (using pre-fader aux in Console).

@@MattHepworth Awesome! Thanks Matt!

No

It works with any DAW, technically, but without the DSP functions it's not a good interface for DAWS other than PT. This is given proper attention in the video as well.

I don't have enough experience with Matrix, unfortunatley. We'll see if that changes. ;-)

@lastcall9998 check out some of that info in the second video - kzfaq.info/get/bejne/etqDgsV9ubKqpYE.html at about 3 minutes and moreso where it comes to plugins from 5-6 minutes. Each Apollo version is different at 44.1 or 48kHz, but the base number at 96kHz is 1.1ms.

BTW, I do have detailed numbers for all models.

@@MattHepworth Thank you Matt. I watched that video. I'm sorry if I seem a little dense, I just perceive when you say those numbers that you are speaking about Monitoring Latency through the DAW, not direct monitoring. Could you clear this up for me, please? I have a Motu M4, its Direct Monitoring is instant, or so it seems, but doesn't have plugins ofc to use in that chain (hardware direct monitoring I believe).

I'm not sure if the Direct monitoring is before or after the converters on the M4, so it's going to be somewhere between 0 and 1.5ms for direct monitoring most likely. Apollo's Console (DSP monitoring) is 1.1ms base at 96kHz, but depending on the model of Apollo you have, it'll be between 2.2 and 3ms base at lower sample rates (which equates to roughly half the latency of a typical native interface that's at its lowest buffer while using DAW monitoring). Apollo's NATIVE DAW monitoring latency is between 2.5 and 5ms at low buffer, depending on sample rate. Almost half the UAD plugins add zero additional latency (in DAW or Console). Some can add over 1ms each, with most the latest plugins having 55 samples of latency. I typically experience less than 2ms latency at 96kHz WITH plugins, but I'm picky about plugin latency, so I'm not stacking four latent plugins on there and I tend to favor the zero latency options. You can achieve 1.1ms with 4 plugins in the chain on Apollo, if you're selective about which you use.

@@MattHepworthThank you very much Matt for taking the time to answer. For some reason I thought hardware direct monitoring wasn't affected by sample rate, but I guess using the dsp within the Apollo interface it matters, right? I am looking for a Twin X Quad to pair with my Macbook M1. About plugins adding latency and choosing some that do not, yeah, I understand that. Ty. Bow to you Matt.

Great review though. I've always wondered just how good the AAX DSP plugin eco system is and you've answered that point blank; pretty terrible basically.

Thanks for the comments! Yes, AAX DSP is quite lacking in options vs its predecessor. There's no reason not to use your Mytek or Burl with Carbon or Apollo. I always use 16 channels of external conversion with Apollo or Carbon and those are for my primary tracks. I prefer my Apogees, but neither of these units are inadequate conversion-wise. Like anything, if you have top shelf conversion use it instead. The recording platforms, however, are probably the top two. HDX is not a superior platform and there's no clear solution like there used to be with HD Accel.

if best dac/ad conversion on the planet is what your looking for, then prism is at top.

@@rvishal6318 I don't think so. I actually kinda hated Prism. Sorry :(. Clinical but sterile. Some of the others were musical first but allow you to be clinical when you need to. If you're restoring old masters and source material that's degraded then maybe Prism is a good choice. But if I had to listen to it all day in production or mixing or post (especially production I should say because maybe I could put up with it in mixing/post) I'd be miserable day-to-day. It's a dac designed for something but I don't think that something is production work.

32-bit.

TotalMix provides around 0.7ms latency, if I recall correctly. The downside is like you say-no tracking through plugins.

@@MattHepworth no it's a lot better than that. 0,068 ms, so "only" off by one digit (at 44,1 kHz) at least that's what it says on the manualslib site: "From a technical view there is no zero. Even the analog pass-through is subject to phase errors, equalling a delay between input and output. However, delays below certain values can subjectively be claimed to be zero latency. This applies to analog routing and mixing, and in our opinion also to RME's Zero Latency Monitoring. The term describes the direct digital path from the interface's input to output. Digital receiver buffers plus TotalMix and output transmitter show a typical delay of 3 samples. At 44.1 kHz this equals about 68 µs (0.000068 s), at 192 kHz only 15 µs. The delay is valid for ADAT and SPDIF in the same way." Hard to beat.

@@akagerhard 3 samples. Wow!

@Gerhard Schöner It looks like 0.7ms is correct. Converter delay plus TotalMix (1-3 samples). This is from Matthias at RME. At 48 Khz, analog in to out via TotalMix FX, input and output channel have EQ, LC, Dynamics and AutoLevel active. Rev/Echo do not change these values: 48 kHz: 0.7 ms 96 kHz: 0.33 ms 192 kHz: 0.16 ms The manual says at 48 kHz AD 13 samples, DA 7 samples. One has to add some samples for the internal routing FPGA to/from DSP plus one sample TM FX, which results in about 33 samples at 48 kHz. Half and another half at 96 and 192.

​@@MattHepworth that's very interesting, thanks! I've looked long and hard to find out false information as it seems! The information I posted IS misleading in that case, because it sure makes it sound like the complete path is accounted for, yet it leaves out converters appararently. So the DSP takes 10 samples in Matthias' calculation? I guess I'll have to think about recording at 96 kHz and check out wether I perceive the difference. Thanks for double-checking my information and correcting me!

I've not used the x16, unfortunately. The DA on the line outs is the same as the other X-series (very good sounding) and are objectively superior to Carbon. The Monitor outs on the x16 have specs superior to just about everything else available.

@@MattHepworth ohh wow thanks for your answer, I already subscribed. Cheers.

Thanks!

Thanks for watching!

@@MattHepworth I was waiting for your next videos. lol. I watched another video on mixing with hardware inserts by Andrew Masters. I tried to test/duplicate what he was doing but I experienced no latency in Protools when I inserted a hardware compressor. I tried it with Logic and the I/O utility ping showed 2 samples. I was happy but also unclear why I didn't have the same results as Andrew.

Many vids in the pipeline. Had some flooding, so I just got things back together and started shooting again.

@@MattHepworth Sending blessings your way. Hope you made out ok. I lived in New Orleans up until 2006.

Many thanks. We got off easy, especially compared to people in other areas and we're pretty much back to normal.

This is true, however, with low budgets for records these days it's hard to justify 24 outboard front ends. Even at my studio we only have 16 channels of boutique outboard, and not enough channels of top-shelf dynamics and EQ to cover them all.

@@MattHepworth oh by no means I meant to have that many. Just a stereo channel setup. Maybe 2 500 series 1073s and two 1176 compressors should be enough for most tracking. And maybe a 8 channel interface for drums.

The Clarett TB interfaces CAN be sub 2ms, but only at 96kHz and only with a buffer of 32. For smaller projects it works fine, but not once you're rolling on the project and have to do more overdubs. The PreSonus Quantum can do sub 2ms even at 48kHz, in fact. However, the issue is the native solutions still can't maintain that low latency throughout the whole project, while the DSP solutions can. When comparing DSP solutions, these two are pretty much the only choices with this type of feature set. Even if you're using outboard (which I regularly do as well), you still need to be sub 2ms throughout the entire project, unless you're just recording yourself and you're personally comfortable with higher latency.

The only classic/studio staple they have is the Purple (1176), but it's high latency, unfortunately, which kind of defeats the purpose of being DSP.

@@MattHepworth interesting. That's sad to hear. I'm on an x8p now and sick of plugin latency combined with round trip latency from mixing hybrid. Been debating the switch to Carbon or Antelope Galaxy 32 with an HDX card

@@alaronthemixm

In a recent firmware update they enabled ADAT to be switched to S/PDIF, but they use the same port, of course. You can use either ADAT or S/PDIF. I feed 8 channels of ADAT out to my Sypmphony for connection to external devices. I use two of those for main output. I use Carbon outputs for the talent, though, as that's the lowest latency.

@@MattHepworth Ok that's great so you could use something like a DAC 1 converter for monitoring fairly easily?

Yes. I think Carbon DA may be in the ballpark of the DAC1, though.

@@MattHepworth ah ok that’s good to know.. is it about the same as the Omni on the DA side?

I can't say for sure. They're similar spec-wise, though. I feel like Carbon's probably better, but it's been too long since I had an Omni.

Interesting! Although I have an Orion 2017 I haven't used its DA, so I don't have an opinion there. Objectively, the Carbon DA has lower specs than most other current devices. Subjectively, it certainly doesn't sound bad and I happily use it for tracking, but not for mixing.

@lawrencehitti4575 - actually, the converters in the Burl are less than $10. It's very unlikely Carbon uses the converters from the 192s (those are 20 years old and obsolete). Pretty much all manufacturers use the same four brands of converters - AKM, CL, BB, and ESS. Even Burl (AKM, primarily). It's not the actual converter that's expensive (they're all dirt cheap), it's the circuitry surrounding the converters and powering the converters that makes them excellent, good, or just mediocre. I have not opened my Carbon, but there are images of an opened unit available on the net and you'll see it also uses cheap, $10 converters.

Good comments. Make sure you watch part 2 for the other perspective (Apollo focused). Everyone has a different sensitivity to latency. Some can't handle latency over 2ms when it comes to vocals. For Apollo to achieve that you need to be 96kHz. For Carbon you can be 44.1kHz, but with both you have to be careful what plugins you use, as they also add latency (though there are over 100 UAD options that don't). BTW, I concur that you should almost always use Console. The second vid finishes the comparison.

I also have an Orion. Quirky, but a great value.

@@MattHepworth what to do you mean with "quirky"?

@@gregrelmueab2142 I experience various and random issues - things like the settings not opening the same each time, random relaunches of the Launcher and Orion software, difficulty managing mixer presets, occasional muted outs or ins for no reason, etc.

@@MattHepworth bummer for you, sorry to hear that. so far its been nothing but awesomeness, no issues for me. I know they have a bad past with QA and/or support but I wanted to see for myself, I mean, I can always send it back. But so far its been amazing with pro tools and currently using 24 outs into a burl B32, way more than i was getting with my apollo 16.

Roughly. I/O is also halved, unfortunately.

Matt I watched the video with great interest. Is it correct to understand that when using carbon at 96k, the latency is half, which is 0.375ms? I read an article that says that if you turn off "Ignore errors during playback and recording" in the protools settings during recording; the latency will be even lower. @@MattHepworth

I do not believe the ignore errors option will change the latency. Carbon is indeed 0.38ms at 96kHz. There's nothing faster, currently.

It doesn't have dedicated surround support, but it can be achieved via standard methods (pretty much the same way normal HD I/O units work for surround), so I don't know that it's really a fault. PT doesn't support surround unless you use Ultimate/Flex anyway.

@@MattHepworth oh, thanks for clarifying that one. I don't know why avid makes it complicated how the communicate things. So it's not a "carbon" problem. Cause the last time I asked their people, they said carbon doesn't support surround, when all along it's a "PT" thing and they are taking about software requirment, when I'm only asking about the hardware as is. So you are right , its just like any interface. This kind of communication from avid is really strange, I understand they are forcing people into PT, but everytime people asked them about something about hardware, they still assume hardware and software is interchangable. Thanks for clarifying.

Thankfully, I've found the fan to be near-silent in the rack after one of the more recent updates, but the fan still makes the talkback completely unusable. Really bizarre design choice. I had an Omni long ago. Carbon is considerably quieter than Omni now.

Buffer doesn't affect the latency when we're talking about DSP monitoring and recording, which is kind of the only reason to use DSP these days - reliable low latency.

Sort of. The simple goal is what goes in is what comes out (effects and all). The ideal workflow would be whatever plugins you put on and process with will be processed that way on the way in (with near zero latency) and playback exactly that way with no need for changes. The same plugins you'll keep during everything stage of the whole project. Separate mixers provide a low latency path, but not with the plugins you're planning to use start to finish. It's not a new standard, but reached its peak with PTHD Accel more than a decade ago. With PTHD Accel no longer supported, there's been a huge hole for those demanding the next best thing to analog tracking with outboard. HDX was supposed to eclipse it but doesn't. Carbon is the closest thing, while UA provides a different approach where you can print just like analog outboard.

Ok, so I believe I did understand this correctly and I guess I would say this comes across as being presented in a right vs. wrong way (i.e. ideal vs. less than ideal) but really it's a workflow comfort and choice. For my production work in tracking, the priority for me is to ensure that the musician has the top comfort in performing and that the system captures that reliably. For me, everything else is a different process of production and mixing where I don't really care about latency at all (other than being annoyed if there is a noticeable delay in pressing play and hearing the start of playback). I just can't imagine where the limitation of real time processing would be worth it but that seems to be a production workflow preference and comfort vs. anything right or wrong.

Matt universal audio plug-ins in console do add latency. Your comment at 5:44 is a bit misleading

@Alan Rich There are over 100 UAD plugins that do not add any latency in Console (or in the DAW if you enable Live Track). The rest do add latency, though. I also talk about that latency aspect in there. Check out my UAD plugin latency chart link on my channel home page for the complete details.

@@MattHepworth the good ones add latency. That’s why I said it was a bit misleading 👍🏻

Assuming no converter delay (which, of course, isn't possible), the smallest theoretically possible latency at 192kHz with a buffer of 64 for RTL is 0.67ms, so, more likely, your RTL is around 0.75ms at 192kHz, which is comparable to Carbon at 44.1kHz. Very usable latency, as long as you're okay with the increased resource hit. Keep in mind that a buffer of 64 samples is on the input, and the output. Since we're dealing with ms the math is really simple: 128/192 = 0.67.

​@@MattHepworth Thanks for being specific, I value your approach. I know how to calculate all this stuff and I keep track of RTL for my different converter combinations, I didn't mention RTL cause I was making a basic troll post. I should have posted that it's ADL + L + DL + L + DAL. Where ADL and DAL are the DA and AD converter latencies, L is the buffer size latency, DL is a [possible] driver streaming mode latency for I.e. USB if applicable. It's not ever close to 0.67 ms RTL, the ADL and DAL are actually bad problems depending on the converters. As for the resource hit, it's pretty bad at 64 samples and 192 kHz. But if you keep up with the fastest possible CPU things have been getting better. I have to be selective about the plugins. Some are CPU monsters at 192/64, and many plugins cannot be used because they introduce latency for stuff like oversampling, linear phase, FFT, lookahead. That limitation would also apply to the Carbon. Zero latency plugins tend to be lower CPU usage so that helps.

It includes a perpetual version still, fortunately.

Yes, but the plugins add latency. Some add a lot. A few only add a little. You can very easily have a plugin chain on Carbon or HDX that exceeds the latency of native with the same plugins due to the lack of prioritization for low latency with the AAX DSP plugins, ironically.

@@MattHepworth Why wasn't this an issue with TDM? It was just another DSP system, no?

No. TDM was a low latency DSP platform, while HDX really isn't focused on low latency. A typical TDM plugin was 3 samples. A typical HDX plugin is 34 samples. Add a comp, an EQ, and Tape and you're at ~100 samples on HDX. You're around 10 samples with TDM, so, roughly 10x as much latency with HDX once you involve plugins. Yes, you can use a few that are lower latency, but the lowest you'll get is 10 samples per plugin on HDX, and that's only a handful of good ones.

@@MattHepworth Is this part of why ProTools didn't have faster-than-realtine bouncing with TDM, or was that just an architectural thing?

@helmanfrow I suspect that's part of it, but don't really have any details there. Thanks!

Most plugins add 0.75ms latency on Carbon. Some add much more, and a few add less. It's the lowest latency without any plugins, but you have to be really careful with plugins, since AAX DSP plugins can add a lot of latency. So can some Apollo plugins.

I'd say it matters less once you're above 110dB, but the difference between 110dB and 120dB in practical usage can equate to a little lower noise floor in your recordings, which can matter. Of course, most releases are still released as 16-bit, which only allows 96dB dynamic range, so it really depends on what you're recording and how it'll be released.

That's a tough pill to swallow. Fortunately, Carbon includes a perpetual license.

@@MattHepworth I heard you mention that, is that for whatever version its up to whenever the year runs out? then to update further you have to go subscription? thx Matt! c

@@chucknkd Exactly. They call it perpetual parachute.

@@MattHepworth not anymore

@@tutengenezemuziki Nothing has changed.

Yes, pretty difficult to use outside of Pro Tools especially.

@@MattHepworth i thing if You need a récording bands i need see another interface , become apollo has good virtual sounds good preamps( buuuut) You can't recording good music y analogic is like a fuck moment

You're not alone in that sentiment!

@@MattHepworth i left Avid on PT 7, now i picked up a used Avid S5 fusion to escape pc and visual based workflow🎉

Nice setup!

Go avid! I would not have a job if I wasn’t an expert with pro tools.

While I agree that there are *subjectively* better converters with lower dynamic range, Carbon's DA are not those...

How so? Which Apollo do you own?

@@MattHepworth apollo twin x duo i have also used the x6-8

It did not live up to the hype i mean i was good and better than a cheap interface but compared to prolevel gear doesnt even come close like the carbon blows the apolo out the water in terms of sound quality and dsp features (i know poeple will debate this) they said apolo no latency when tracking even with plugins what they forgot to say that each plugin you add adds samples of delay so its not latency free i know then carbon is similar but they tell you how much each plugin will add in latency. Also im a pro tools users and love the integration with the software.

Carbon's integration is hard to beat! I don't know if you watched part 2, but I cover the cons of Apollo and also make my recommendation as to which to buy.

@@MattHepworth yes i did i watched them back2back 😃

Apollo is lower latency than most native systems and can have no noticeable latency, but there are a lot of factors. If you're one of the cursed people like me (and a small percentage of the vocalists I've worked with over the years) that are highly sensitive to the comb filtering, then you'll need to stick to Apollo at 96kHz and be careful with what plugins you choose. At 96kHz Apollo is only about 1ms latency base, which is truly excellent.