Hello…
This is what I see.
Below is my MQA authentication path…
Hello…
Now my iFi Pro iDSD is directly connected to N+. It is working fine. This is what I see.
And below is MQA authentication path…
1 Like
What I meant was the idsd pro is not Roon Ready and never has been so is not affected to by any of this. Its a DAC that can be connected locally to Roon core or another Roon Ready endpoint or act as an endpoint using Squeezelite and the Ifi bridge software that runs on a Windows pc. You don’t need to connect to a pc just the bridge software needs to run on one. I cant say which sounds better that’s up to your ears to decide and is very system dependant.
1 Like
Kool… Now I get it… Thank you so very much.
Hi,
Would you know why the Purple changes to Blue during iDSD MQA Full decoding?
Regards,
Tushar.
MQA is not lossless, it’s enhanced due to the nature of it.
1 Like
No - they work fine, at least my M11 does 
However, never tried ‘mobile’ Roon - all that VPN just a pain. Happy just to use Qobuz on the road.
Thank you. Actually I meant having Core with me during family and business trips. This a thing that I love Roon for. Just copy backup and music to USB stick, plug it into laptop and restore. 5min and done.
Please would someone explain what the advantage is of a device that is ‘roon ready’ and therefore requires certification?
For example I was looking at an ‘Allo usbridge signature’ and asked the company if they were affected. Apparently not as their software utilises Roon Bridge and RAAT - anyone know what this means? But surely this means that the appliance is still ‘roon-ready’ in the way we interpret language (ie the device works with roon)?
What unites the devices that are affected, are they devices that don’t use RAAT/Roon Bridge but use their own software to connect to Roon?
It would be really helpful to understand this as it is so confusing.
There are two wonderful inventions: writing (~3400 BC) and search (~1995 AD).
https://kb.roonlabs.com/Roon_Ready
https://kb.roonlabs.com/RoonBridge
12 Likes
For the short version, it applies to manufacturers who have incorporated the RAAT SDK in their firmware, or otherwise, which then allows them (once properly certified) to claim Roon Ready.
Not sure what the status would be of some manufacturer who reverses engineered the RAAT SDK and then wrote the appropriate code to interface with Roon, if that even makes sense.
Devices with RoonBridge are exempt from this new policy.
1 Like
… but typically RoonBridge endpoints and attached DACs, as well as Roon tested systems like Linn, have more limited Roon functionality than Roon Ready endpoints.
Yes, that’s true. As far as being marked as un-certified, I guess I should have said ‘exempt’.
Editing now. 
Sorry for asking but does anyone know where Linn devices stand in this respect? Specifically in my case an Akurate DSM /2?
I know that Linn refused to go RAAT on the premise that it wasn’t open source, but then some compromise was reached and a DSM firmware was released that working with Roon (and did not use AirPlay 1 with its resolution limitations).
That was enough to make me commit to Roon, but as the Roon functionality was ‘sanctioned’ by Roon and Linn formally working on it I’m in a grey area as to whether I need to apply For the ‘developer’ fix or not in order to retain a working system?
I know Linn didn’t deliver ‘full fat’ RAAT and some other solution was agreed / deployed, but without the details I am clueless as to whether the ‘uncertified device’ situation will apply to me or not?
I’m currently not upgrading my CORE until I know, so any clarity would be hugely appreciated… thanks
Not affected.
Awesome - thank you
To be more specific: Linn accepts the Songcast protocol, which Roon Core implements so that it can talk to Linn devices. This connection is not as tight as for a RAAT/RoonReady setup regarding control (for instance, not all the buttons on the Linn remote work with Roon) but it works well for basic play. I’m happy enough with my Roon > Linn setup. It’s labeled as “Roon Tested,” not as “Roon Ready.”
So you are saying that a hardware company wants to include RAAT and be ‘Roon Ready’, rather than a ‘Roon Bridge’, in order to allow greater functionality of their product. What is this greater functionality you mention? I am genuinely interested as I am in the market for a network bridge (that is, a streamer with no dac) and would like to know what extra potential I get from a licensed ‘roon ready’ device over a cheaper pi-based ‘roon bridge’ box. It is not really clear at all from any of the info I can see on the links you offered before.
From the KB article on the details of what RAAT will give you (and hence what is possible when RAAT is implemented into a device’s firmware, i.e. a Roon Ready device):
Two-way control integration . Artwork and now-playing information can be displayed on hardware devices. Front-panel controls and IR remotes can control Roon via the device. Volume controls on device front panels can be kept in sync with Roon. If you’re talking to a device that has multiple inputs, and start music in Roon, the input automatically switches to Roon’s input. Anyone who’s used Roon’s Meridian integration knows the value of this set of capabilities.
The precise list of functions and features depends on the device in question. For example, to display cover art and album details, the device needs a full-colour display with sufficient resolution…
And to give a further example, here’s a device that I hoped (when I bought it) would become Roon Ready: the QUAD Artera Link. Had it done so, then I would have had two-way control of volume (from Roon or from the Artera) as a minimum, and potentially also support of DSP functions. Alas, QUAD never followed through with this, so it remains connected via an RPi4 + RoPieee running Roon Bridge.
1 Like
As owner of Pi-based RoonBridge boxes (several different ones over time), they receive from the Roon Core and send to the DAC a digital audio stream, but they do not connect DAC functions like standby or remote to the Roon Core. For example, if I change volume on my Sonnet Morpheus DAC with its remote, Roon does not see that. Not surprising, given that the connection from the RoonBridge device to the DAC is carries just digital audio, not control signaling for those other functions. To have greater integration as is supported on Roon Ready devices (modulo device constraints), there has to be a tighter hardware integration, with the Roon Ready processor working hand-in-hand with the internal controls of the DAC. Does that answer your question?
1 Like