Hello Ron and others,
Although it has been quite a while since you’ve posted this extended workaround for Direct Hardware Monitoring, I would like to thank you nonetheless for this great alternative. It has gotten me to rethink my setup and planned expansions.
Although the MR816(CS)X is considered an old interface now, in my opinion it is still one of the recent Steinberg interfaces with the most potential flexibility. Therefore I would like to explore, discover and elaborate on the concept of direct monitoring over multiple daisy chained MR-units.
I own two MR816X units and one UR824 unit. Currently the UR824 is my master device and the two MR816X (standalone mode) are slaved via ADAT. This setup has proven to be very reliable. This setup containts 24 analog inputs which I can directly monitor (low latency) from the four stereo outputs. The problem with this setup is that it is not further extendable and the UR824 is in fact an 24x8 interface (instead of a 24x24 interface) when it comes to routing and direct monitoring. I’ve never understood why there are only four stereo “mix” sends on this unit considering the older MR-units had eight stereo “mix” outputs. This restricts the UR824 from routing at least every input to every output (something that the MR-units are capable of) and it is also not possible to have all four cue mixes and one stereo master mix directly monitored because that would need at least five stereo “mix” outputs. In terms of routing, this units has the least routing options out of the MR816 and ARX4.
The MR-units are truly 16x16 interfaces and they are extendable by daisy chaining one or two additional units via firewire. One would think this would result in a 48x48 interface, but unfortunately this is not the case. Total direct monitoring in such a setup is not available for the two additional units and therefore this setup could be best described as a (16x16)+(16x16)+(16x16) interface. This has been covered extensively on this forum and there have been enough topics and frustrations about this. In retrospect, Steinberg might have tackled this issue not as professional towards their customers as one would expect from such a company, in terms of transparency and speedy replies concerning this issue. Wether they knew this limitation on forehand or not, they could not have solved this issue by soft- or firmware upgrades as I think it is almost certain that hardware modifications would be needed. More on this a few paragraphs further in this post. The recent news that Steinberg dropped support for the MR-units is an extra disappointment, because I believe it is a waste, economically for existing MR-owners and also sustainably in terms of lifespan of an otherwise great interface.
Obviously I’m aware of the newer AXR4 model, but I didn’t had the chance to check this one out in real life yet. Apart from it’s price point, this unit seems to “suffer” from the same problem as the MR-units when daisy chained. As described on page 55 of the AXR4 manual, you have to use adat connections to directly monitor from additional units. To me this comes across as the same workaround for the MR-series.
So, I need more in- and outputs, preferably 32-40 inputs. For the most part these inputs are external synths and live-instruments so they have to be directly monitored on the master bus. Furthermore, I need to be able to route any of these inputs to 16 inputs on a personal monitor system (Behringer P16 or alike) and preferably some of these inputs need to be submixed and routed as a stereopair to this personal monitor system (e.g. a stereo drum- or key bus) to save on inputs on the personal monitor system end.
Totalmix by RME would be able to do this easily, and the personal monitor system would even be optional. But the integration with Cubase would be lost and I personally hate going back and forth multiple applications. The AXR4 is quite expensive and somehow is still not flexible enough when it comes to daisy chaining multiple units. The Nuage IO units have dedicated cascade busses over CAT5 to solve this problem. Unfortunately these units are even more over my budget.
Therefore I’ve been elaborating on the workaround Ron posted. I’ve also looked at the “official” https://helpcenter.steinberg.de/hc/en-us/articles/206108384-MR816-Monitoring-without-latency workaround, but that one seems unnecessary complicated to me. Also, this setup uses almost all CUE mixes (why are there only four CUE sends anyway? There are enough bands with more than four members)? I still have a few questions about this whole setup and maybe some of you would like to help me out. Hopefully this would also be helpful for other MR816X owners to grasp the infrastructure of this daisy chained setup. Attached to this post I’ve uploaded a routing scheme of what I think is going on when MR-units are daisy chained. This post might be way to extensive for anyone to join in, but hopefully a bunch of you are still using MR-units and are willingly to dive in.
When looking at the schematics or simplified block diagram I made, it becomes clear why direct monitoring over multiple units is indeed a problem. Without direct monitoring there are, in the maximum situation where one would have three MR-units daisy chained, a total of 96 (48in’s and 48out’s) audio channels over the firewire bus. The 16x16 internal DSP mixer of an individual MR-unit with it’s 16 input channels and 16 busses cannot communicate “directly” to the other MR-units. If you would directly monitor an input on MR-unit number 1 on an output on MR-unit number 2, the signal has to pass over the firewire bus through the daw and back to MR-unit number 2 and therefore causing latency. If Steinberg would design the units as such to prevent this they would have to create “connecting busses” with at least 48 bus signals and 48 inputs signals. I don’t know much about firewire bandwidth, but my guess is that if these busses and inputs should travel over the existing firewire lines (on top of the already 96 channels that travel over firewire) the bandwidth of firewire is not able to accommodate this. Also, presumably, the proces to translate the DSP signals to the firewire protocol and back, might cause extra latency (I’ don’t have very much knowledge about the firewire protocol, so I’m not sure about this)
So, here are a couple of thoughts on this setup, they might be right or wrong, please correct me if I’m wrong or feel free to add your expertise/opinion. Maybe even some employees from Steinberg are willing to add to this discussion. It would be nice to include the numbers for reference.
Preface
De idea is to build a stereo sumbus where each of the internal dsp’s mixers of the individual MR-units can connect it’s main-stereo bus onto. This example has a few assumptions:
- Full version of Cubase with the MR-extension is installed.
- Sample rate: 44,1 or 48Khz.
- Three MR816(CS)X daisy chained by firewire.
- MR-units operation mode: 6-channel adat and 2 channel S/PDIF
- S/PDIF cable from output MR-unit 3 to input MR-unit 2 and,
S/PDIF cable from output MR-unit 2 to input MR-unit 1.
- Stereo monitor system connected on two of the eight analog outputs or on two of the eight digital outputs (adat or the S/PDIF) on MR-unit 1.
- The remaining 6 adat channels on each of the MR-units or free to use for external preamps, etc.
The main point is that only when signals are processed whitin the internal DSP mixer of a MR-unit (meaning that inputs can only be routed to outputs on the same unit), direct monitoring without latency is guaranteed. As soons as you route a signal through the firewire connection latancy is introduced.
1. By using the S/PDIF (2-channel), one would only connect a stereo bus to another unit.
(A similar setup would be, let’s say, three 16 channel analog consoles patched their main (master/stereo) bus into the next console and have the speaker system connected to the last console to expand the number of inputs in this system to (16+16+16-2-2=)44 inputs).
That would mean that any other busses, other than the main stereo/master bus are not directly monitored in this approach. If you would monitor with a 5.1 system for example, this solution would not work as you need six busses/channels instead of two channels/stereobus. Also, one or more additional cue mixes on top of the stereo mix with an output on the first unit would not be able to monitor signals for the second or third unit without latency, unless you would also connected additional busses over multiple units somehow. One idea might be the use of the 8-channel adat connections which should end up in a eight-bus summing solution for 5.1 or other uses. Unfortunatly you would loose the adat connections for external pre-amps in such a setup.
2. By utilising the S/PDIF approach, one would need to have two stereo tracks in Cubase to route the S/PDIF signals from the second and third MR816X units. If you would be using a DAW other then Cubase, you would control routing parameters in de MR-editor. But with the MR extension installed, Cubase controls the routing and levels of the MR816 internal DSP mixer.
What needs to happen in Cubase is that the S/PDIF input on MR-unit 2 (carrying the output sumbus from MR-unit 3) needs to be routed to the S/PDIF ouput on MR-unit 2. In order to do this a stereo track in Cubase is required. The input of this stereo track has to be set to “S/PDIF in MR-unit 2” and the output to “S/PDIF out MR-unit 2”. When this channel is monitor enabled, a signal flow from de sumbus of MR-unit 3 to the S/PDIF output on MR-unit 2 is realised. This ouput stream is now the stereo sumbus from MR-unit 3 mixed with the sumbus from MR-unit 2.
The next step is to route the combined sumbus from MR-unit’s 2 and 3 to the input of MR-unit 1. Create an extra stereo track with input “S/PDIF in MR-unit 1” and output whatever you have your monitor system connected to on MR-unit 1. This injects the sumbus from MR-units’s 2 and 3 into your main monitor bus on MR-unit 1. Remember to also monitor enable this track.
One importing thing to remember is that the output bus from the input channels comming from MR-unit’s 2 and 3 have to be set to S/PDIF output (sum) bus of the corresponding MR-unit. If one would set the output bus on these channels to your main-monitor/stereo bus on the first MR-unit, the signal has to traveller over firewire causing latancy. See also point 3 where I initially made this mistake.
2a. Only digital connection (adat/S/PDIF) could be used to sum a bus from other units into the next. When an analog in- and output would be used there is extra latency per unit connected due to the latency from the AD and DA converters, comparing to signals from the unit where you physically monitor your stereo master bus from (which don’t have this “extra” AD and DA set and therefore latency).
2b. Other busses, such as sends and studio/cue sends cannot be directly monitored in this setup.
The problem with, let’s say, a studio/cue send is, that you you have to set the output bus for the complete bus. This differs from the main stereo bus, because you are able to set de individual output bus per channel. So let’s say you have selected an output pair on MR-unit 1 as the output for studio/cue send number 1. When monitoring input signals which are connected to this same first MR-unit there are no problems, but monitoring input signals from MR-units 2 and 3, again, this bus has to travel of firewire and therefore loosing the direct monitoring.
3. Considering the setup without the S/PDIF connections. I’ve connected my monitors (stereo) to analog output 1 and 2 on the first MR816x unit. When in “direct monitoring” mode, a signal from the second MR816x should not be audible, since the second MR816x has no speakers connected to any of the busses. Against Logic, when pressing the monitor enable button in Cubase, a sound is still audible. This means, even when “direct monitoring” is enabled, signals from the secondary MR816 are still passing through the firewire connection to the DAW and back (with latency obviously) via the first MR816x unit to my monitors . That got me thinking that the S/PDIF connection (summing bus) would double this (delayed) signal??? Is there a way to not monitor the sound through the firewire bus? EDIT: The statement I’ve made in the Italic text is wrong. I made a mistake as the output bus of the mix channels coming from the second MR816x should be set to the S/PDIF output bus on the second MR-unit. This bus is summed back in the main-monitor output by feeding it back in on a monitor-enabled stereo channel. I’ve made the mistake to have routed the input channels of the second MR-unit to the main-monitor output of the first MR-unit, forcing it to monitor trough the firewire bus.
3a. In addition to my retrospective fallacy in point three: maybe one could return the S/PDIF summing signal from the second and third unit on an “external input” in the control room?
4. If you would use a personal monitoring system like the Behringer P16, you should only route analog or adat inputs to analog or adat outputs on the same MR-unit for enabling low-latency monitoring. If you would feed an input source from MR816x (1) to an output on MR816x (2) to the P16-I, the signal has to travel over firewire through the DAW causing latency.
5. One could use Cue-mixes to submix inputs from the same MR-unit to output to e.g. a Behringer P16 system. For example: If you connect let’s say 12 drum microphones on the first MR-unit and you would be submixing these with e.g. Cue-mix 1 to outputs on this same MR-unit, this should end op in a stereo, low-latency, drummix on the P16-system.
6. In the “official” workaround by Steinberg and the extending workaround from Ron there are steps included which describe making edits in the MR-editor. I’m not sure why this would be necessary as I was under the impression that Cubase would overwrite any settings in the MR-editor as soon as Cubase is started/launched.
7. Another idea is to skip the internal summing all together and use a 3 stereo channel - stereo line mixer (for example: PowerMIX III – Three Channel Personal Stereo Mixer – ART Pro Audio) for every stereo output bus to combine the stereo output for every bus on every unit. If you would do that for every stereobus (2x8=16) you would theoretically end up with a 48x16 interface. All outputs would be in use in such a system.
I would like to apologise for this rather extensive post on a quite old topic of a discounted interface. 
MR816.zip (298 KB)
