# Mac, PC, Universal Audio and Thunderbolt



## utopia (Apr 7, 2014)

Hey everyone. Here's what I'm thinking.
I've been working with a duo of a master mac mini and a pc slave (samples). While my PC has been doing great the mac mini often gets pushed to its limits (fx processing, minor sample libraries). I'm on Cubase 7.5 and I know that Cubase runs better on PC. So I've been thinking to try to make a switch. However, as my audio interface is an apogee duet (1st gen) that also means ditching that and having to get a new one. I made myself a promise of NOT getting any hardware that does not work equally well on both platforms - never to be tied again.
Enter UA. I've been eyeing UAD plugins for sometime and would definitely like to try to get on the boat at some point. The Apollo would be my ideal choice as it would combine both the sound card upgrade I need AND get me into the UAD land. Apparently, it was designed to be a firewire/thunderbolt interface. The UA folks clearly show that PC market is not their primary focus (FW being a dying standard, no PC thunderbolt support for original apollo, apollo twin not supported on the pc at all). 
Which leads me to questioning - why choose such a strategy and loose a large portion of the market of PC folks? I know thunderbolt has had a slow start on the PC land, but it is gaining momentum and with news like http://www.macrumors.com/2014/04/07/intel-expands-thunderbolt-networking/ (VEpro on steroids anyone?) it could become a great technology for us.
I guess I don't really have a question here, only hoping this will change and UA will become a great choice for cross platform use - I know many professionals who switch from Macs to PCs regularly. Until then I guess I'd have to look for other options for my setup.


----------



## Simon Ravn (Apr 8, 2014)

Get an RME soundcard and a UAD-2 PCI card - more stable than Apollo as well.


----------



## utopia (Apr 8, 2014)

Hey Simon,thanks for the advice. Unfortunately,this solution is not optimal as: a) i still have my mac mini and a macbook pro that i'd like to use for mobile recording (also through uad plugins) and b) the total cost of a decent rme interface + uad pci card would be much higher than getting an apollo. What would be perfect is an apollo with true cross platform support. I hope ua seriously considers the option of supporting pc thunderbolt.


----------



## jaeroe (Apr 8, 2014)

what model/specs mini and mac book pro do you have? i have 2012 mac book pro retina with apollo thunderbolt and it's working great - very stable, fast, powerful. i have a 2012 mac mini same spec. obviously, you'd be contending with Cubase on mac os if you went that route, but i know good composers using it on mac os and loving it. large templates, etc.

re PC and thunderbolt - UAD is not unique in that department. the demand isn't there on PC yet - not talking about the music world, just PC world in general. once it is, people like UAD will likely put the recourses in. they had announced it with the initial release of apollo, but i think shied away as thunderbolt failed to take off as quickly on PC.

i was in a similar situation with getting a new interface last year for my big/main rig. i ended up building a hackintosh with thunderbolt. if you're into building computers, it works great and is very cheap - comparatively. nicely powerful. you just can't get anything above quad core at the moment, as thunderbolt requires integrated graphics, and the only sockets that have that now top out at quad core. hopefully this too will change soon.

but, on the PC side, i think you can get something like RME multiface II and PCIe card plus UAD quad for the same price at Apollo thunderbolt. i don't think PCIe will be going away from PC anytime soon, and i think there are plenty of mac people who will be using PCIe cards in mac pro's for a while to come. Protools HDX systems are still PCIe only, and they are industry standard for audio. it just involves a thunderbolt chassis expander. the price on those will come down over time, as well. and that would be your route for a 'portable' option if you went PCI.


----------



## jaeroe (Apr 8, 2014)

Simon Ravn @ Tue Apr 08 said:


> Get an RME soundcard and a UAD-2 PCI card - more stable than Apollo as well.



what stability issue are you having with Apollo?


----------



## Simon Ravn (Apr 8, 2014)

I am not having any - I decided to get an RME UFX in addition to my UAD card instead of going the Apollo route after reading all the DSP reset/crash stories on the UAD forum 8)


----------



## jaeroe (Apr 8, 2014)

that might have been on v5 software, but it's very stable for well over a year now.


----------



## Nick Batzdorf (Apr 8, 2014)

Why not keep the interface running on the machine it's running on, and send the audio from whatever Windows thing you use over Vienna Ensemble Pro?

Put another way, why would you want to get rid of a perfectly good audio interface?


----------



## EastWest Lurker (Apr 8, 2014)

Nick Batzdorf-political Liberal, technology Reactionary


----------



## Nick Batzdorf (Apr 8, 2014)

And yet when you think about what I actually say, you find that I'm always right.


----------



## Nick Batzdorf (Apr 8, 2014)

On a less serious note, times have changed, and it's time for everyone to un-train themselves from the habit of mandatory buying the same shit over and over and over again.

I just got off the phone with a music editor friend, who told me his rig for 100+ track Pro Tools film sessions with multiple stems is his 3-year-old MacBook Pro. He bought an older one at the time because he wanted the FireWire port (he didn't realize the $29 Apple adapter works).

Point being that this implementation of Moore's Law is over. The computers from the past several years have had more than enough power for almost everyone, so the only way for companies to keep selling machines is to change the ports.

By the way, everyone is whispering that Thunderbolt is dead. It's being replaced by Thunderectum™ in June, at which time Apple will stop supporting USB.


----------



## utopia (Apr 8, 2014)

Hey guys, thanks for your replies.
Nick, if I understood you correctly you're asking why bother to replace my current apogee duet if it's still working? Well as much as I hate it, it doesn't really work the way it should. I get constant stuttering,audio dropouts etc even when sometimes watching youtube videos/playing back audio files. The drivers are bad. The only way to fix this would be to reset the device by unplugging/plugging back in. And then after some time the problems return. This started from a few OS version back and apogee really aren't showing any will to deal with these problems. Makes the whole experience of working quite painful. 

jaeroe, I have the mid 2011 mac mini server with 16 gb ram. Also an old 2007 macbook pro (obviously, it only has the FW ports). I just don't want an expensive interface that I wouldn't be able to use on my machines (at least the PC and mac mini). 
The PCI in a thunderbolt chassis is a good idea, though somewhat less elegant than a native thunderbolt solution.


----------



## AC986 (Apr 8, 2014)

Nick Batzdorf @ Tue Apr 08 said:


> x
> 
> By the way, everyone is whispering that Thunderbolt is dead. It's being replaced by Thunderectum™ in June, at which time Apple will stop supporting USB.



What!?!??!!

If they do that they can stick that up their ass!


----------



## Simon Ravn (Apr 8, 2014)

jaeroe @ Tue Apr 08 said:


> that might have been on v5 software, but it's very stable for well over a year now.



Go read the thread - there are still people today having problems. And a lot of them on V7.x... Definitely not as stable as a PCI card / RME combo 8)


----------



## Nick Batzdorf (Apr 8, 2014)

utopia, in that case you're right to replace it.

This is part of what I love about Metric Halo - they're offering a board update even for their 13-year-old 2882 interface:

(Sorry for the long quote)

We have announced a set of Core technologies that will form the basis of an upgrade for existing MIO's, LIOs and ULN-8s as well as the basis for future products. These Core technologies are comprised of the following:

1) USB2 Class Audio with MH sureClock transport.
- This provides 192 channel (96in/96out) communication at 1x rates
- The audio clock and the USB transport clock are decoupled in HW

2) MH Router
- This provides 1024x1024 channel router @ 192k on every unit
- The router transports audio in one sample
- All audio sources and sinks are connected via the router
- 1024 channels is large enough that it is effectively infinite

3) MH Link
- Each unit has 2 MHLink ports
- Each MHLink port provides 128 channels of audio in and out @ 192k
- Audio is transported with 1 sample of latency
- This is built on the Gigabit Ethernet Physical layer
- Connections are on Cat 5
- Cables are inexpensive and ubiquitous
- Cables can run 100m between nodes
- Connections are transformer coupled, so no ground loops
- Fully integrated with the MH Router
- Transports audio clock

4) MH Link + MH Router Enabling Technology:
- No more aggregate devices
- No more legacy I/O to bridge mix busses from box to box
- Makes all boxes look like one box to the mixer and the computer

5) MH Router integrates all I/O in the unit
- USB
- MH Link
- ADAT
- AES/EBU
- SPDIF
- Analog
- MADI
- Not all products will have all I/O types

6) In practice, the combination of MH Link and MH Router mean that audio can be transported from the input point on one box to the output point on the next box
with 4 samples of latency, and each additional MHLink hop adds an additional 2 samples of latency.

Since all boxes have two MH Link ports, you can chain boxes as you like. Unlike FireWire and USB, the MHLink is not a bus, so each link has the full bandwidth available to it in both directions.

Since we integrate Automatic delay compensation into the system, effectively each box that you add to the system adds 2 samples of system latency.

For example, if you have 8 boxes to implement a 64 channel system, the system will add 16 samples of overall latency to ensure that all channels are aligned regardless of which box it comes from. This amounts to 333 microseconds of additional latency if you are operating at 48k. At higher sample rates, the latency scales down.

The presence of the router on every box means that any input on any of the boxes can be routed or multed to any output on any of the boxes. This includes the USB, which could be connected to different computers on different boxes.

7) Since the computer transport is USB Class Audio, the units can be used with any host that supports USB Class Audio -- this includes Mac OS X, iOS, Windows and Linux.

8) Of course, in keeping with our commitment to future-proof products, this is an upgrade for every FireWire interface that we have ever shipped.

There have been many questions about what we discussed and I wanted to clear as many of them up as a can. Please find a bit of a FAQ below. In addition, we'll be posting a tech talk that goes into some additional detail. The talk has been recorded, and it is being edited now. We'll post a link once it has been posted to YouTube.

Here is the list with the most asked questions:

*** Q1: I don't understand; is this an upgrade or a different box?

This is an upgrade. It applies to every unit we have ever shipped. 13 years ago, we said future proof, and we meant it.

*** Q2a: USB 2.0? not USB 3, Thunderbolt etc.?

The USB 2 is what we consider to be the baseline for the upgrade and future products. There are a few important points as to why we choose USB2 as the baseline:

1) Every single device you would want to use these with supports USB2 and USB2
Class audio.
2) Neither USB 3 nor Thunderbolt have class implementations for audio - so that
means that custom drivers are required, and for the platforms that do not
support custom drivers, that means that you simply cannot interoperate.
3) We have been able to implement an exceptionally capable transport layer on top
of USB2; we can do 96 channels in and out at 48k (192 channels total) which
far exceeds the needs of most of our customers.
4) We have this all working now.

That does not mean that we will not implement USB3 or Thunderbolt. It just means that we are not ready to *talk* about it yet.

*** Q2b: But if you use all the UBS2 bandwidth how do I add a USB drive to the USB bus?

On the Mac (at least) each USB connector is on its own bus. So you can use the different connectors. That being said, if you use a USB3 hub, the USB2 and USB3 busses are actually completely separate (on the same connector) -- so you can attach the interface on USB2 and a USB3 drive, and the two devices will both get full bandwidth.

*** Q2c: Multiple boxes on one USB 3.0 port using a hub might come in very handy…

You don't need to do this because of MHLink -- multiple boxes on the USB bus gets us back to the situation with FireWire -- where each box is independent and you need an aggregate to use them together. MHLink aggregates in HW.

*** Q3a: Will the old FW ports remain, or will everything be swapped so that only the new USB/MH Link interfaces remain?

Everything will be swapped. All the computers that support FireWire also support USB2, so there is no compatibility break, and maintaining support for FireWire would increase the end-user cost of the upgrade.

*** Q3b: Will USB2 bus-power a Mobile I/O?

No.

*** Q3c: Will USB3 bus-power a Mobile I/O?

No.

*** Q3d: Will ThunderBolt bus-power a Mobile I/O?

No.


*** Q4: When I connect multiple computers which will show the Miomixer? All of them or is one the master?

We are still working on this, so we are going to defer answering it until we have a more complete story to tell.

*** Q5: Can I record to two computers at the same time for redundancy?

Yes.

*** Q6: What's all this about 1 sample of latency and USB?

The USB latency is higher than one sample (obviously). USB2 uses 125 microsecond isoch periods. Latency on the USB bus is quantized in units of isoch periods. In the sureClock implementation, we need to have 2 packets plus a couple of samples of safety offset on the input and output side of the USB. The 2 packets correspond to 250 microseconds of latency in each direction.

On the computer side, there is some additional transport latency due to the way that the USB hardware works -- 2 or 3 packets worth. So that is an additional 250-375 microseconds.

On top of that you have the audio buffer latency that is determined by the size of the audio buffer you choose in your host -- that's going to be the same regardless of the transport protocol.

All told the transport latency adds up to around 1 - 1.5 ms (maybe a little bit more) at all sample rates. This is consistent with what we were able to achieve on FireWire.

*** Q7: So very exciting - love the Ethernet connectivity - love to hear the details on USB in/out latencies. But isn't the 1 sample stuff is being taken way out of context?

It is a little bit, in that the USB <-> Computer latency is higher, and is generally dominated by the buffer size you choose for the host.

But the latency is 2 samples per hop (1 sample for input to the MH Router and 1 sample for output from the MH Router) on the box -> box connection, which is much, much lower than anything that can be achieved with other high-bandwidth transports and allows for the aggregation of boxes in a way that we cannot achieve on USB, FireWire or something like Dante.

The latency would be achievable on something like MADI, but MADI does not have the channel counts that we can attain with MHLink, nor does it have the bandwidth for control data, and it has much more expensive and less generally available cabling.

*** Q8: How is MADI integrated?

The tech is done. The realization in specific products is still being determined.

*** Q9: Is this a real ethernet connection? If yes, wouldn't it make sense to connect the device via ethernet to your pc?

Yes it is a real ethernet connection. It is possible to connect via the computer. That being said, MHLink generates packets at a much higher rate than computers really want to deal with, and there are real challenges in getting the latency down to what we wish to achieve when using an ethernet connection that is controlled and shared with a GP OS with a full networking stack.

In addition, while it may not be the case for PCs, in Mac and iOS, current machines do not ship with Ethernet connectors on the hardware, so you are back to needing an adapter. That is not the case for USB.

*** Q10: How can USB be superior to FW in aspects of CPU load and performance?

Modern USB HW uses the same DMA engines that FireWire used. All the data transport is done via DMA, and does not require CPU intervention. In addition, USB audio transport is headerless, so there is no need to do payload extraction and header pre-pending for USB (whereas it is required for FireWire), so the actual CPU intervention is lower for USB than for Firewire.

*** Q11a: Are the 96 channels a total channel count?

It is 96 in and 96 out at 1x (44/48) rates (so 192 total). For each doubling of the sample rate, the total number of channels goes down by half. So 2x rates are 48in/48out and 4x rates are 24in/24out.

*** Q11b: Is this tied to the number of boxes?

No -- the USB channel I/O is controllable independently from the number of boxes, so, for example, if you are mixing in the MIO mixer on one box, you would be able to do so with a much higher number of output channels from your DAW, without having to add additional boxes (for channel count). Depending on what you were doing, you may need more boxes for DSP.

*** Q12: Why is that high channel count not achievable with Firewire?

There are two components for overall transport performance - the capabilities of the computer and the capabilities of the device. The current MIO hardware implements the FireWire protocol layer on a DSP, and a significant amount of the overall limitations are due to CPU and bus bandwidth limitations on that HW. In addition, on the Computer side of things, the number of DMA contexts that is required to be supported by a FireWire controller is fairly low (we pretty much only guaranteed of having 4 input DMA and 4 output DMA contexts).

So those combined together limit the ability to stream the theoretical maximum channels. In contrast, with sureClock, we have implemented the USB transport layer in hardware (without a software component), and that allows us to reach the actual channel bandwidth of USB. In addition, on the Computer Side, USB controllers are required to support DMA for all endpoints up to the bandwidth limit. So bottlenecks are removed on both sides of the USB.

While we could implement the sureClock on top of FireWire as well, at this stage of the game, there really is no point, because every machine with FireWire also has USB, but many machines with USB do not have FireWire.

*** Q13: What's the timeframe?

Some time this year. We'll firm that up when we can.

*** Q14: What's the cost?

Not yet determined, but it will be affordable.

*** Q15: Can we have exact features?

Of course not! As Gustav Graves said in "Die Another Day" -- "It's not a secret. It's a surprise."

*** Q16: and how it's going to become available ?

For existing users, it will be an upgrade like the 2d Card was; new masterboard and new backpanel. It will be field-installable, and we will also offer a factory upgrade service.

For new units, it will be included as part of the unit.

*** Q17: Are there pictures?

Not at the present time. The development hardware we have is not representative of the final product.

*** Q18: How and where is the +dsp available and how do we control it. In class compliant mode especially.

All of the processing you have come to know and love on our hardware will be available on the new hardware - simply with more available DSP. For example, the Firewire transport engine consumed all of one DSP and about 15% of the the other DSP on the 2d Hardware. sureClock uses no DSP at all. The MH Router would consume 100% of the 2d DSP; on the new hardware it uses no DSP at all. As far as the specific forward looking aspects of your question -- we are still working on this aspect, and we'll share more when we can.

*** Q10: I only have one box -- why do I care about this?

Four reasons:

1) Interoperability with whatever platform you want to use at the moment.
2) More of what you already love about your box -- more processing, more
channels, more plugins.
3) Easy expandability -- if you need more in the future, you can add more
seamlessly.
4) The new processor architecture has a minimum of 1000 times the available
memory as compared to the 2d Card. This means that the memory limitations
that occur on 2d are simply gone.

If you have further questions, please post them and we'll do our best to answer when we can.

Best regards,

B.J. Buchalter
Metric Halo
http://www.mhlabs.com"


----------



## utopia (Apr 9, 2014)

Nick, thanks for these.
I actually read the thread at gearslutz and I was very impressed to say the least with MH strategies. Surely that's the way every company should treat their customers.
Then again, the whole thing for me was that I wanted to combine getting a new audio interface with entering the UAD land. Which is really much more expensive if you buy a similar to apollo MH unit + the UA PCI thing. And you wouldn't be able to use it on different computers (the PCI card), AND you wouldn't be able to track through UAD plugins, and it's less portable etc etc.
I guess there's no perfect solution (o)


----------

