One thing to keep in mind–just because they entertained an interview doesn’t mean that MQA suddenly started spilling even more details in their partner relationships. For the most part, what’s in the interview is the same as the information that we have.
How would this work in Roon with a device like the microRendu? Would the last part in ‘MQA decode 2’ take place in the microRendu or Roon server?
The server is the more sensible place from our perspective, but Bob’s answers (as you noticed) do not address this clearly, so we’re not sure.
A few thoughts on this:
- Forcing each RoonReady partner to license IP from MQA one by one (as would be necessary if each one was going to distribute an MQA decoder) seems like a big hassle and slow-down for MQA. However, it would also enable them to collect more license fees.
- If DAC-specific profiles were used, Bridge manufacturers would need to issue firmware updates to distribute new ones, which would add more slow-down and hassle for everyone.
We are in a great position to manage those details in a single place in the server, but as before, we still don’t know whether we will be allowed to or what exactly it will look like.
Would microRendu (or any RoonReady network endpoint) be able to report back to Roon server which DAC is connected, to enable selection of the correct DAC profile in MQA?
YES. We built this capability into RoonReady and RAAT from the beginning, in part because we were aware of MQA’s sensitivity to DAC identification issues. We can extract the identifying information from any USB device connected to Roon or a RoonReady bridge.
That said, the world is not quite that simple: not all DACs can be positively identified over USB–many manufacturers take a shortcut and call their device “FooCorp USB Audio 2.0” instead of “FooCorp Product”, or neglect to use unique USB identifiers for each product. We have no idea if or how MQA will elect to handle cases like this, since in those cases it is impossible to really know exactly what the DAC is.