We asked Bryston to pull it because they released a Roon Ready to users without submitting their integration to us for review/certification first. The review process is a requirement of the license agreement for Roon Ready–it ensures that our shared customers are getting the experience that they are supposed to be getting, and that we are prepared provide competent support if they are issues. It’s something we have always been clear on, and the review process is something we present as a feature/benefit to our users–so we take attempts to skirt it seriously.
As for Bryston’s timing–the pace of the review process is largely up to the device manufacturer, and we aren’t in a position to make statements about schedules of other companies. I am not aware of any reason why they would be waiting on us at the moment. They might be willing to provide an update if you ask.
As for Bryston’s SQ: My understanding is that that issue has been resolved internally within Bryston. They did not contact us for technical help on this point, so we never learned the details. I know that the SQ stuff was the subject of a rumor mill, but I wouldn’t read into it too much. All it says to me is that a product was made available to the public before it was ready. I don’t think it really provides insight into what is going on within Bryston or within Roon.
From our perspective, the pace of RR adoption is speeding up, not slowing down.
Some general comments regarding some of the other points:
-
The most technically trying parts of RR integration are not related to audio. They relate to user-experience touch-points like volume control, source selection, standby, settings, and parity between RR and other input options. On devices with well-engineered, centralized infrastructure for managing this stuff, it goes quickly. On others, RR might motivate some infrastructure work on their end.
-
RAAT has some basic system requirements that exclude certain weaker devices, particularly devices that don’t have a modern fully featured kernel and networking stack. This is largely about ensuring stability, reliability, and future-proofing. It also means that some older-style platforms are left behind. Tough choice, but we think we’ve made the right call for our and our users’ future.
-
Some audio companies do not build their networked audio modules in house. Their core competency is in analog circuit design, or DSP, not in networking. Involving a third company that must be paid, must schedule the work, and so on and so forth, adds months to the time-to-market. We’ve worked through several of these situations–they take time. On the flip side, each of these third parties is typically tied to multiple products and multiple brands, so getting through one of those enables a lot of products to be released.
-
Going back to add features to existing products is more work than integrating it into future plans. Some of the manufacturers we are working with are approaching RR this way, so RR support in those brands is waiting for product releases entirely unrelated to what we are doing.
-
Lots of companies say lots of things before/during/after trade shows that don’t become true, or don’t become true for a long time. The socially normative thing to do at/around trade shows is to say yes a thousand times and then work out the details later. This is just part of how the industry works, not something I would read into too deeply.
Without visibility into what’s going on, it’s very difficult to guess why a particular manufacturer is taking a while to release, or why they are/aren’t supporting RR at the moment, or why they may have changed their mind. We can share what’s going on within Roon (and I’m happy to take any questions on that topic), but we really cannot share the private internal details of other companies–it’s up to them to decide whether or not to be open about that stuff.