So, we have the function of supporting multiple audio interfaces (input/output) in applications such as Zoom. In the mastering world, we know that many engineers still love to use an analog chain along with a digital mastering plug-in chain.
For those of you using Nuendo, would you like the option of being able to use two separate audio devices to provide I/O for your analog FX racks?
If you’d like this feature within CuBase, please give this a vote. Thanks in advance!
You can already use multiple audio interfaces so I guess what you’re really asking for is using multiple interfaces of different brands. Correct?
I think it would complicate setups and give more users headaches. Also, is this not already possible using some ASIO drivers out there?
My understanding is, you can use multiple interfaces of the same hardware, yes. It also requires they both run at the same sampling rates, which, in mastering may not always be desired (less crucial).
Case:
I use an analog mastering chain, but my DA and AD converter/interfaces are completely separate devices and neither support bidirectional DA/AD conversion. Currently, I must use a separate DAW and Wavelab to accomplish this. Many mastering engineers use separate physical hardware devices, often for their characteristics. Other very expensive mastering DAWs do support this functionality, but at 6+ times the price of Wavelab. I have tried using an Aggregate interface in Mac OS, which accomplishes this, but exhibits glitches in the captured audio.
My understanding is, Wavelab cannot support this function unless Steinberg will enable this functionality in the BAIOS driver, which may take votes to get any traction.
As for complexity, in Cubase and Nuendo, as with any other DAW, this function can be disabled by default and hidden from view for those who might use a single hardware interface unit. Sampling rate changes aren’t absolutely crucial.
Hope this helps!
@soundporter if it is just about having more analog I/Os, then just simply get an extra A/D D/A converter device(s) and connect it to the installed audiointerface.
I’m using an RME interface and separate RME A/D D/A converters, run them via ADAT and MADI. Works like a charme.
Easy as that, all the best
Thanks for the response. It may help clarify my scenario:
Mac OS out USB-C → (D/A) Benchmark DAC3 B → analog chain → (A/D) Crane Song HEDD 192 → MOTU 8D (for AES-to-USB conversion) - Back to Mac OS
For your RME interface, what hardware are you using that allows you to offboard your AD/DA conversion to separate devices?
What happens if you go to your Benchmark from your MOTU digitally instead? That way you only have the one connection to Nuendo. I know the Benchmark doesn’t have wordclock i/o, but you could try maybe?
Yeah, I’ve considered a few options here, including that. Unfortunately, the Benchmark doesn’t use word-clock, as you alluded, but its real diamond in the rough feature is the extremely accurate and fast USB locking ability.
I’ve considered using the MOTU 8D as both I/O with just the Crane Song. However, I believe the Benchmark to be a more transparent D/A, and I also use it to feed my outboard master metering–something the Crane Song isn’t able to do.
To place a finer point on this: I believe Sequoia and Pyramix(?) offer the ability to use disparate audio interface hardware for I/O, since they know the engineers like to choose different converters for D/A and A/D.
I’m using a RME Fireface UFX+ interface, a RME ADI-8 DS MKIII and a RME M-1610 Pro
Another scenario would be, that if I were to use my Crane Song HEDD-192 as both D/A and A/D for the mastering chain, I’d still like to use another audio interface for D/A to my monitoring system so that I can separately apply SonarWorks room correction without affecting the mastering chain, if that makes sense.
I’m using a RME Fireface UFX+ interface, a RME ADI-8 DS MKIII and a RME M-1610 Pro
Yeah, it’s the same general solution I have with the MOTU 8D, but I’m obviously limited to AES/EBU or S/PDIF. My thought process is to spend a few thousand more to get more hardware to do this right, or use that cash to buy Sequoia (I’ve loved WL for 15+ years now, so I hate to switch). So, if Steinberg had the support to allow this scenario in the software drivers, this could save someone like me thousands.
It may be worth looking into comparisons between using its USB input versus S/PDIF. My guess would be that it clocks the signal internally regardless of source and so the question is if there’s any audible difference when switching inputs. If there isn’t then I don’t see a reason why you wouldn’t make the MOTU the center-piece.
It may be worth looking into comparisons between using its USB input versus S/PDIF. My guess would be that it clocks the signal internally regardless of source and so the question is if there’s any audible difference when switching inputs.
Yes, indeed. I have gone through many resources to see if S/PDIF might be a usable option (it is), but the latest USB 2.0 allows asynchronous mode, meaning it can run completely independent clocking between the devices, as the data is buffered. There’s virtually no clocking error with the latest USB technology. S/PDIF is synchronous, and like AES/EBU, it uses the same basic protocol, it suffers from lower voltage and therefore susceptible to more noise. Plus, because the audio is encoded onto the clock signal, it stands to be degraded if the clocking is out of sync.
Personally, I still feel the hardware audio interface/DAC industry still hasn’t seen the true power of Ethernet, which is quite open-source. Only Dante and SoundGrid, and a handful of AVB interface manufacturers seem savvy. This is one area where the MOTU 8D and Apple nailed it.
Any by the way, thanks for the suggestions. It’s got me re-thinking my rig, anyway. 
Here’s what Benchmark has to say about jitter and their inputs:
This system keeps all jitter-induced distortion at levels that are at least 140 dB below the music. This level is so low that the jitter-induced distortion would be inaudible if it was played by itself. Any digital audio signal that can be decoded by the DAC2 will be reproduced without audible or measurable traces of jitter-induced distortion. This means that the optical, coaxial, and USB interfaces on the DAC2 deliver identical jitter performance. Furthermore, the jitter performance of the DAC2 is not a function of cable length or cable type.
(from here: Inside the DAC2 - Part 2 - Digital Processing - Benchmark Media Systems)
Thanks! The problem using the MOTU as a sort of I/O hub is, it doesn’t automatically detect and switch between sampling rates from an external clock (lame, I know, and MOTU Support said the same to me). Since the Crane Song HEADD-192 is set to 48kHz, the rate I use for capturing (most cases), the MOTU is hard-coded to that rate as well. The benefit of the Benchmark for outgoing D/A is that it can switch rates on the fly and super-fast. As for the jitter section you mentioned, that’s no longer a problem in DAC3, since you can choose AES/EBU, but the routing from the MOTU seems to be borked going to the Benchmark over coax.
It would seem my only prime option is to purchase a much more expensive hub solution for I/O.
I’m in camp “try to use one interface”.
Mainly because of the headaches involved with separate audio drivers, clocking, etc.
There are excellent interface that are 8 channels and above which can do great in a Mastering situation.
I hear good things about Metric Halo hardware and software (ethernet support).
R3LAY Virtual Patch Bay would be great if it ran on Mac OS, but I may have found my solution, and in an even better way. At least it helps with one of my challenges of multiple outbound interfaces. It still doesn’t seem to solve the problem of an inbound interface.
One really cool benefit is, you can add a plug-in (like Sonarworks Sound ID) to calibrate an output.
For the first time I regret that we only have Windows computers in the studio. 
So, I ended up using Audio Hijack for my needs. It’s more solid (Ginger Audio Room crashes), and solved pretty much all but a slim few audio challenges I’m still working through now.
