I have a general question about “Roon Ready” certified devices: it is about the corresponding updates.
Over the past months there were several Roon software updates involving the Roon core (e.g. Nucleus) and Roon endpoints (e.g. on Mac OS, iOS, Linux Roon Bridge), which extended the Roon capabilities and/or fixed bugs (e.g. Roon 1.4, Roon 1.5, and minor revisions). Over this time period there was no update of my Roon Ready DAC/Streamer (i.e. firmware update). Does this mean that my device did not get the corresponding improvements or is this just handled somehow “in the background”? Or do I need to push the manufacturer of the device to release a new firmware?
Manufacturers are in control of updating their firmware. Some have been hanging onto an old version of RAAT for some time apparently. As to what impact this has, that is a difficult question to answer. I thought that Roon always maintained compatibility with older RAAT versions but clearly if there are any improvements that impact sound quality, you will miss out until the manufacturer gets round to updating. Whether these changes make a difference will be device specific too, I expect.
Personally I’m not a fan of this approach - I’d like to see some sort of minimal commitment to keep pace with RAAT versions, say no more than 12 months out of date, but I guess that generates a whole bunch of extra work for both Roon and their partners. I guess a ‘nudge’ approach might be to publish the RAAT version/age on the product matrix but, again, it needs maintaining. I posted on a similar topic a while back - Roon Readiness - any ongoing commitment? .
Without some sort of detail as to what each RAAT version gives you functionality wise (where this impacts the user or sound quality), this wouldn’t be much use. It also overcomplicates the simple designation ‘Roon-Ready’.
In any case, if you are determined to buy a product because of the way it sounds, RAAT version makes no difference to your product choice. The easy way to always get the latest RAAT is to drive your chosen DAC from a separate endpoint via USB/coax. RasPi plus HAT is the easiest way into that and should always be at the latest version; though that depends upon the OS used on the PI (?).
Manufacturers don’t support hardware forever, only a few years if you are lucky. So I expect it will be the norm for many endpoints to get ‘stuck’ on a RAAT version, with fairly minimal impact for the end user. Roon will keep working to those devices.
From what I understand about RAAT, the endpoint hardware runs the base RAAT “BIOS”, when the Roon Core connects the Core extends the RAAT “BIOS” with updates / new functionality. Thus for the most part it avoids the need for frequent endpoint firmware updates from the endpoint manufacture.
Unfortunately I agree with you that being “stuck” is likely to be the norm, and I accept that other approaches would be more complicated, but in my view they would be preferable to the end user. As @Chrislayeruk mentions, the recent Bluesound update is a good example of why people might want this (though sadly it did not fix the sync issues that some of us had hoped it might).
Meaningful updates to RAAT are not that frequent. As @Carl mentioned, a fair amount of the code is delivered from Core->Endpoint “just in time”, too, which relaxes the pressure on firmware updates quite a bit.
At this point, the actual SDK releases are mostly about:
Fixing rare bugs
Adding support for quirks of new hardware products that haven’t come out yet
So there isn’t much of a point in pushing existing certified to do work/take risk in updating if they aren’t hitting the bugs and don’t have those quirks.
MQA was an exception to this, since that was a major new feature in Roon and required the subset of devices that have their own MQA support to play catch-up.
Bluesound is a somewhat different situation, since the remaining issues as I understand them would not be fixed by simply updating the RAAT SDK.
Thanks @brian for clarifying things a little - I confess I’d missed the point made by @Carl which does provide some added reassurance.
I guess part of it then comes down to not wanting to miss out on whatever “major new feature[s]” might arise in the future. Maybe this is about how one views the endpoint hardware - to me, it’s basically a disguised/modified computer and should update itself as such. Others might say it’s basically a piece of HiFi kit and if one wants new features one should buy more kit (or add an RPi as a proxy).
Edit: That said, it’s not all about new features. In the case of Bluesound the sync bug was not investigated by BS earlier, probably because it was anticipated (by both Roon and BS) that it would be fixed by a RAAT update. Thus an artificial dependency was created, an unintended consequence of RAAT being so behind in the first place.
Brian, thank you for this explanation. Thus, if I understand it correctly, a Roon Ready endpoint device (i.e. its internal software/firmware) is more robust with respect to required/relevant updates than the other Roon endpoints, since it gets the relevant code always from the Roon core.
This triggers a further question: Why is this mechanism not also used with the other Roon endpoints (e.g. Roon Bridge, iOS), i.e. as a software implementation of a “RAAT-Roon-Ready system”?
In the Roon Knowledge Base there is the short topic “What is RAAT?”. Is there a possibility to get further (technical) information about RAAT or is this a “secret topic”?