@AMP:
Will the Rossini set the filter to M1 when a first-unfold happens elsewhere (assuming the stream has the rendering bits obviously)?
I would assume the network bridge will indeed not touch the stream if it is first-unfolded already, correct?
This depends on how the stream is being delivered. If it’s over the AES, S/PDIF, or USB interfaces then, yes, it will be rendered correctly as long as the MQA authorization bits are set to verified. If they are set to unverified then the Rossini will not decode them. This latter limitation will change in the next update.
If the decoded stream is delivered via the network interface from Roon then the rendering function will not engage. This is a limitation which will be removed in the next release.
Before you ask… I cannot comment on the next release as it is contingent on something that is not yet public. All that I can say is that it is something that will be released soon pending some other development efforts.
In its current state (today) the Network Bridge is not MQA-aware and will simply pass the PCM bitstream through unmodified. After our MQA release is published (really soon) it will be subject to the similar limitations as above. We anticipate to have this corrected in the follow-on NBR release which is due in June.
Two problems popped up late in our development cycle on the Bridge and long after the Rossini MQA code was released. In other words, about 2 weeks ago. We have a plan in place to address one of them and it will be folded into the release cycle for the applicable products. The other is still under investigation and we should have a plan in place in the coming days.
I have a Vivaldi stack. Once the MQA update is issued, i assume that no decoding will be done in Roon as the MQA-capable Vivaldi will be detected in Device Setup. Am I correct?
Your stack should be detected as a Decoder and Renderer. If you choose not to apply DSP, then Roon will pass-through the 1x MQA stream unmodified; but you will also have the option to apply DSP in Roon, in which case Roon will perform the first decode, apply the DSP, and re-embed the “signalling” information necessary for MQA Rendering (in your stack).
Moved this to a separate topic as it wasn’t specific to the forthcoming Network Bridge update.
That was my question, thank you.
What if I selected the M1 filter manually? Obviously it would not switch by itself since what you’re telling me (I think) is that the signal to engage M1 is coming from the network card as it detected and unfolded an MQA stream whereas the stream is already unfolded in this case and thus the network card is not aware.
I might well be completely wrong as you’re telling me that the SPDIF interfaces do switch filters automagically.
The M1 filter is only available when the FPGA has the render function enabled and the problem is that due to an unforeseen issue the renderer is not engaging.
Right now the best bet is to let the Rossini do the decode and render as before. If DSP functions are needed then they can be enabled, but you’ll have two choices:
- Disable Roon’s core decode function completely at which point DSP will be disabled for MQA content.
- Leave Roon’s core decode enabled at which point the MQA renderer in the Rossini won’t engage.
Not sure if this is the right place for this question. But here goes (also raised this at computeraudiophile site):
With Roon 1.5 released with MQA first unfold, and with MQA first unfold soon availalbe in the Network Bridge, what will be the optimal means for playback in systems incorporating both, irrespective of DAC in the chain? Is it best to have, as in my case, the Roon core running on my Nucleus perform the initial unfold, or disable this and “enable” MQA on the dCS NB and have it do the first unfold, passing the bitstram on to my Berkeley Ref. 2 capable MQA DAC?
Is the limitation discussed above apply in any way to my hardware configuration? Seems not, as my Berkeley DAC, though having its own filters, does not set any explicit limitations on upstream factors. But who knows just what’s been tested of this actual chain…
In general the best practice is to have the MQA decoder as close to the renderer as possible. In this case that means utilizing the decoder in the Network Bridge for all scenarios except those involving DSP being applied to MQA playback. The correct setting under Audio in roon is MQA Capabilities == Decoder and Renderer.
If you are referring to the DSP limitation then this may or may not be an issue with your DAC. Roon sets the MQA authentication bits a certain way (per MQA’s guidelines), but some DACs do not perform MQA rendering on streams set this way. The only way to find out is to try it and see.
If the DAC does not properly recognize and render the DSPed stream then this is an issue that you’ll need to take up with Berkeley as it has to do with how they are processing the authentication bits.
I’ve got 1.5 of Roon installed today. My Berkeley DAC has been capable of rendering for quite some time. But now I have the ability to unfold and send through the dCS NB to the DAC. Roon does not “see” the downstream DAC at all as it it not Roon Ready. However, in testing with a few samples from http://www.2l.no/hires/ when I change the dCS NB settings for Device Setup from no MQA support to Renderer Only I am able to get the DAC to display MQA and the following is noted under Signal Path
Not sure if this is the correct setting based on your comment.
When the new firmware becomes available, would it make more sense to have the NB do the first unfold leaving the DAC to render as it will be the closer of two possible decoders to the Berkeley renderer , or let Roon do the first unfold? I’m assuming that this is possible and that the NB will pass along the MQA authenticated bitstream that should be detected by the DAC.
Andrew
Sorry but this is absolutley new. This now occurs on almost every track and this only occurred in the past when I started a new MQA album or when i interrupted the MQA signal for more than a few seconds. It now occurs at the beginning of just about every track on a MQA release.
I think you mean:
Decode in bridge --> Roon needs to be set to decode+render for the DAC connected to the NB
DSP in Roon --> Roon needs to be set to render only for the same
Since you connect your DAC to AES or SPDIF (no other option on the Berkeley) then Roon will never know what it is or the capabilities.
For unfold in Roon you need to configure it as “Renderer Only” (in Roon) and it should work just fine. For unfold in the NB after the update you will need to configure it in Roon as “Decode+Render”.
One word of caution is the volume leveling, which is DSP: Unless the Berkeley supports volume control in the DAC itself, it will not work properly in the case the NB does the first unfold.
D’oh! Good catch. This is what I get for doing two things at once (and neither of them well).
The Bridge needs to be defined with the Decoder capability in audio settings so that it is given decoder responsibilities if there’s a downstream renderer then Decode and Render need to be defined. With these settings Roon will make intelligent choices about when to perform the decode function in the core vs in the bridge.
Edited my post above (twice now since I appear to be having one of those days).
Based on your current configuration you have the correct setting.
When the new firmware comes out you’ll set MQA capabilities to Decoder and Renderer (thanks @miguelito) and then Roon will make the proper choice.
For the initial release the Network bridge will only support Roon doing decoding if it is also performing DSP functions. Roon decoding with no DSP will not work correctly.
That’s bizarre. How is no DSP not DSP? (I know this sounds bizarre)
I need to clarify so as to reduce confusion. There are two processes at work:
- MQA decoding or first unfold
- Roon DSP (parametric EQ, volume leveling, convolution, etc [except upsampling])
If you play an MQA file or Tidal stream and are NOT using any of Roon’s DSP functions then you want the Network Bridge doing the MQA decoding.
If you play an MQA file or Tidal stream and ARE using Roon’s DSP functions then the Roon core has to do the MQA decoding.
This is accomplished by setting the device capabilities to “Decoder and Renderer” in Roon’s audio settings. Roon will make the intelligent choice based on what you are playing and how you have Roon DSP setup (or not).
If you want the Roon core to always do the MQA decoding, but you aren’t using Roon’s DSP then it won’t work in the initial release of the Network Bridge MQA firmware. This will be addressed in the next release due in June.
As an aside, there is no difference between the decoder used in the Roon core and the one used in the Network Bridge. Both are the same algorithm and (as far as I know) both are provided by MQA in binary form.
Hi Andrew,
I m user of NB and Vivaldi DAC
Definitely looking fwd to experiencing the new MQA feature
After going thru all this information on the new setting, I found there may be certain inconvenience for users playing different tracks mix up of pcm, dsd / MQA, meanwhile users are commonly using different dsp features in Roon.
Is it possible to add an individual filter in dsp setting for MQA that when user is going to play MQA, this setup can automatically turn off dsp features so as to stream MQA data to NB while switching back to original dsp setting when the next pcm / dsd files are played?
Not sure is that a concern for other users.
Regards