Any Carbon users who were using UAD Apollo before?

[LukeHoward]

Great comments – just to respond to a few:

Thunderbolt is closely related to PCIe - a relatively direct communication with the CPU, whereas Ethernet is a 'bolt-on' for network communications and requires translation to 'ip'.

AVB operates at Layer 2 so does not go through the IP stack. The default latency (presentation time offset) specified by the AVB spec is 2ms for Class A traffic but hardware implementations such as RME’s can tune this down as low as 0.3ms. This does require cooperating devices for low latency in both directions as the offset is set at the output (”talker” in AVB-speak). It would be difficult for a non-realtime software implementation such as the CoreAudio one to achieve these latencies though and you are correct that PCIe and even USB interfaces are able to offer lower latencies.

Thunderbolt is fast (40Gb/s) and Ethernet is slow (10Gb/s if you're lucky, more usually 1Gb/s).

Audio bandwidth is relatively tiny, 1Gb/s is enough for many hundreds of audio channels (particularly in the case of AVB where the switches cooperate to reserve bandwidth).

Thunderbolt is a point-to-point communication medium, intended for the CPU to talk directly to peripherals whereas Ethernet is a many-to-many communication protocol with lots of things built in to deal with collisions and delays in devices speaking to each other. These overheads create inefficiencies.

Not really an issue with modern Ethernet switches because each port is its own collision domain.

[dominicperry]

Originally Posted by LukeHoward

Great comments – just to respond to a few:



AVB operates at Layer 2 so does not go through the IP stack. The default latency (presentation time offset) specified by the AVB spec is 2ms for Class A traffic but hardware implementations such as RME’s can tune this down as low as 0.3ms. This does require cooperating devices for low latency in both directions as the offset is set at the output (”talker” in AVB-speak). It would be difficult for a non-realtime software implementation such as the CoreAudio one to achieve these latencies though and you are correct that PCIe and even USB interfaces are able to offer lower latencies.



Audio bandwidth is relatively tiny, 1Gb/s is enough for many hundreds of audio channels (particularly in the case of AVB where the switches cooperate to reserve bandwidth).



Not really an issue with modern Ethernet switches because each port is its own collision domain.

I won't argue with any of your points Luke, as my technical network knowledge hasn't been enhanced much since about 2005. If you want to know about DECnet or SNA gateways, then I can probably help.....

So, given that AVB bypasses some or all of the reasons that I identified as being the cause of Ethernet slowness, can you explain why Carbon still has more latency than a direct-attached TB interface? Is it most likely drivers, or Avid's AVB implementation being poorer than RME's, or perhaps something else. Genuinely curious to know.....

Dominic

[LukeHoward]

Originally Posted by dominicperry

I won't argue with any of your points Luke, as my technical network knowledge hasn't been enhanced much since about 2005. If you want to know about DECnet or SNA gateways, then I can probably help.....

Hah! I'm sure there's someone still using DECnet somewhere!

So, given that AVB bypasses some or all of the reasons that I identified as being the cause of Ethernet slowness, can you explain why Carbon still has more latency than a direct-attached TB interface? Is it most likely drivers, or Avid's AVB implementation being poorer than RME's, or perhaps something else. Genuinely curious to know.....

I'm going to punt that they are using the default presentation time offset of 2ms, because they can't change CoreAudio and, indeed, even if they could, it might be harder to get under that in a non-realtime software implementation (for pretty much the reasons you mention).

I should add that latency is pretty subjective and the Carbon may well be fine for VI use, I have not tried it. AVB in CoreAudio circa 2015 was not great with small buffer sizes but, things have probably improved since then.

[chrisdee]

What's got lower latency recording VI's and recording vocals between Carbon and MTRX Studio?

Would be nice to know the numbers for both HDX and Native PCIe.

[chrisdee]

Originally Posted by Kyle Splittgerber

No, you don't need to do that. If you want to process VIs through DSP plugins you can route the Instrument/Aux track running the VI to an Aux running DSP plugins.

So if I want to add a aax-dsp eq and compressor after my Vi track I just send the output of the VI track into the input of the aux track with the eq and compressor on and enable dsp on the aux track?

Then the mixer, routing and plugins runs on Carbons dsp (offloading my cpu)?

[Kyle Splittgerber]

Originally Posted by chrisdee

So if I want to add a aax-dsp eq and compressor after my Vi track I just send the output of the VI track into the input of the aux track with the eq and compressor on and enable dsp on the aux track?

Then the mixer, routing and plugins runs on Carbons dsp (offloading my cpu)?

Yes, that's correct.

[dankin]

I kinda wrote this off when it first came out, but now that I'm really looking into it, I must say I'm really interested. I've been using an Apollo 16bf and Apollo Twin MkII for a few years, I mostly use the Twin for travel, but occasionally use both together when I need more inputs. I personally hate the workflow with Console and PT combined and while Luna is free, it's lacking a lot for me, and having to have an Apollo hooked up to even open it is a huge deal breaker. My only concern with Carbon (based on previous experiences with Avid hardware), is how well does it work with other DAWs? I mostly do midi work in Logic. Is Carbon stable with Logic? No issues with system audio through Carbon while PT is open? For tracking audio and mixing, I have zero desire to change DAW's. I've tried several times and always end up back in PT:)

[K Roche]

Originally Posted by dankin

My only concern with Carbon (based on previous experiences with Avid hardware), is how well does it work with other DAWs? I mostly do midi work in Logic. Is Carbon stable with Logic? No issues with system audio through Carbon while PT is open? For tracking audio and mixing, I have zero desire to change DAW's. I've tried several times and always end up back in PT:)

I don't know about Logic. But Carbon works fine running Studio One and Reason (although I mostly now use Reason as a plugin in PT), and also works fine as the sound source for Zoom meeting app. through PT as well

[dankin]

Originally Posted by K Roche

I don't know about Logic. But Carbon works fine running Studio One and Reason (although I mostly now use Reason as a plugin in PT), and also works fine as the sound source for Zoom meeting app. through PT as well

Thanks. I feel like I'm sold on Carbon. Just seems like the perfect workflow for me. I'll keep my Apollo Twin for now for travel, but I'm going to sale the 16mkII and Satellites + Plugins.

[K Roche]

Originally Posted by dankin

Thanks. I feel like I'm sold on Carbon. Just seems like the perfect workflow for me. I'll keep my Apollo Twin for now for travel, but I'm going to sale the 16mkII and Satellites + Plugins.

Oh just realized I did not answer your other question
Yes I can have PT open and launch say my internet browser and play Youtube video or my SoundCloud page with the sound coming through the carbon system and then click right back into and play PT