Hello,
I have subscribed to Roon (one year) after Bryston released a RAAT implementation which was later removed from the F/W at Roon’s request on Feb 8 (no other explanation provided). At this point, Roon is of no use to me and I would like to cancel my subscription. Please advise.
Thanks!
The Roon Ready program requires more than an implementation that appears to work. It requires testing and a certification process that ensures that the hardware manufacturer did not implement anything wrong, or in an way that would degrade the user’s experience. For example, the implementation must be tested against other manufacturers devices to make sure that the core features of RAAT are implemented properly (like zone grouping).
There is a second side to Roon Ready, where the manufacturer tests the audio outputted, but I don’t think they’ll mess up that part 
Although the Roon Ready program takes a some time to implement, we have worked closely with the hardware manufacturers at all steps in the process, and have provided them an SDK that takes them most of the way there.
What you have here with Bryston is a release of the RAAT implementation that got out the gate before all of the above could be completed, so they were asked to hold back.
There is no plan to make this permanent. This only happened due to an improper release. We take the release of these implementations very seriously, and an improper release can damage the integrity of the Roon Ready program.
An explanation was indeed given to Bryston, and it’s probably a good idea to not accept the word of an out-of-the-loop engineer as the word of the company.
If you’d still like to cancel, you can do so via your account page, but that’d be a shame. This improper release should signal to you how close they are to completion, and that release is imminent.
At this point they have a BDP and we are waiting for final approvals.
– James Tanner, Bryston VP Sales and Marketing (Feb 15, 2016)
I found this quote about Roon Ready on audiocircle.com where James is very active. I would wait until the software is released before doing anything.
I had a chance to experiment with the BETA release that included RAAT. It worked well for Redbook audio, but for hi-res content I had issues with dropouts at the start of playback.
I am using an Apple Airport Express as a Wi-Fi bridge to the device, with a strong signal (reports a link speed of 300 Mbps, so real-world throughput of 40-50 Mbps would be typical, but of course it’s only half-duplex).
Although this setup works flawlessly for 192/24 WAV playback via DLNA, there doesn’t seem to be enough bandwidth for RAAT. Bryston’s engineer commented on the forum that RAAT uses a lot of bandwidth, implying usage above and beyond the PCM data itself. I ran an ethernet cable to the device, for testing, and things worked fine.
I hope this doesn’t really turn out to be the case, long-term, forcing me to restrict Roon playback to 44.1/16 for devices away from my home router. We’ll see when Bryston does release the approved version.
Hi Kenneth,
I run the Roon Ready partner program, so let me try to clarify things, since there have been a lot of messengers in different locations on this topic.
First, let me say that Bryston has been a great and enthusiastic Roon Ready partner. We met with James and Gary for the first time at CEDIA back in October and we have an enormous respect for the team there.
We distributed RAAT code to partners in November and at the CES our first partners launched, with demos running throughout the show in some very demanding audio environments (Roon Ready drove the TAD and Viola Labs demos, without a glitch, for the entire show.)
There was a beta of the Bryston BDP integration at the time, but there were still some clear bugs to be worked out in their implementation, so it was not demoed at the show.
When the BDP firmware with a Roon Ready beta version was released by Bryston, it still had not been submitted to us for testing and certification. This process always finds some ways to improve the experience and performance and finds some edge cases that haven’t been considered, which is why we require this.
We asked Gary to pull back the public beta for two reasons:
a- the production version of Roon that end users would be using in a public beta would likely be 3-4 weeks out of sync with the Alpha version of Roon with the latest RAAT capabilities, so the tests are not actually useful as information.
b- even more importantly, a major point of Roon Ready is to give end-users confidence that when they buy a Roon Ready device, it will just work. If the internet contains complaints about dropouts, etc (such as you experienced), even if it was in beta, for every partner device, then this confidence will be undermined.
So this is why beta Roon Ready support was removed from the Bryston firmware.
The comment from James about about us having a device and just waiting for certification is something he was unclear about… we do have a BDP, but Bryston has yet to submit code for testing. Trust me, as soon as it comes in, we will be on it immediately and will turn it around as fast as possible… as fast as they iterate and work with us is as fast as it will be done.
As for the comments on the bandwidth requirements of Roon, I think that once the Bryston integration has been submitted, we will work with Bryston and find the opportunities to make their integration more streamlined… RAAT (the underlying protocol of RoonReady devices) was designed for an incredibly lightweight footprint so that it could run on any device alongside Airplay or Google Cast, so there should be no problem here.
I hope this clears thing up.
I just stumbled on this topic, but I have to say to @robdarling and @danny and the whole Roon team, that I wholeheartedly agree with what you’re doing here - and users of RoonReady hardware should be forever grateful for your efforts.
Coming from a device manufactured by people that took the opposite to this approach - i.e. just put streaming technology out there and not really worry about how well it will work in the real world in and in all environments - I’m blown away by how diligently and seriously the RoonReady program is being taken, and even more so considering how new it is.
To the topic starter @Carmen_Marin - I have no connection with Roon other than being a happy user - but I can say with some confidence that should they make my device RoonReady, I would be really thankful that they were taking their time to make sure something’s released that works well, rather than just ‘releasing’ it. There’s a huge difference, and at the end of the day its of benefit to the RoonReady hardware brands, and of course Roon itself, but mostly to the end users who will have a (hopefully) trouble-free experience.
I wish the people behind my device would have done something like this - for there’s nothing more frustrating than buying an expensive box to stream to, only to find out that there are constant problems that can never be solved reliably. I don’t think you’re going to be in this position and thats largely down to Roon’s technology backed by their approach outlined above, and that takes a certain amount of time and dedication. If only more companies followed their example….
I think that the comments from the Bryston engineer were a bit out of line. There were also comments about Roon Labs not saying why they wanted the RAAT beta out, etc., which I also think were unnecessary.
I certainly look forward to Bryston BDP supporting Roon officially in the future. In particular I would love them to implement Roon Server on the BDP’s, as their SQ is excellent, and there would be no need for a Roon Server PC. The Roon UI experience is without par, in my opinion. Since the RAAT beta was removed I just retired the BDP from daily use and normally listen to music using Roon directly to my Devialet 400 via Ethernet.
The BDP’s lack the CPU/RAM to run Roon Core well. Focus on them to be audio endpoints, and put your Core on a bigger machine in the closet.
I wondered about that and thanks for the clarification. The BDPs are fantastic sounding audio renderers and I look forward to using mine as a Roon endpoint.
And, just to be clear: my comments weren’t meant as anything mean spirited and I wholly support the quality first approach Roon is taking. You really only got one shot to make it right; something Roon obviously understands.
Fair enough, once Bryston releases an official firmware with Roon end point support certified (which looks like they will do rather sooner than later) I will compare SQ against the SQ of their MPD implementation, which is excellent.
I am guessing you read that interchange on AudioCircle, as well. There seems to be some concern there.
Yep, at least with the beta RAAT support, MPD had the edge in SQ. That seems to be the consensus, of all who tried it. Roon through Devialet Air to my Devialet 400 seems to be better than the beta RAAT on the BDP, though. Probably Bryston’s RAAT implementation still needs some sorting out.
My guess is hardware manufacturers spend years developing and tweaking their own implementations to extract the best performance until they get something they’re happy with, like with Brystons current offering.
Even if it were true, if the SQ of their current system only had ‘the edge’ over a first-pass unapproved beta implementation of a newly released protocol, I’d say that’s pretty encouraging for RAAT! But no one can really pass judgement until it’s been certified so it makes sense to me that it was pulled.
Hopefully there are people on the other forum explaining things as clearly as they’re being explained here by the Roon team?
The status on the other forum is not clear, regarding why the beta raat support was pulled (which has been explained so well here, indeed) and also, what is the clear direction of Bryston regarding that.
As you guys have gleaned, yes, one of the clear bugs in the Bryston implementation at CES was an SQ difference between MPD and RAAT.
This should not be and is one of the things to be worked out.
As a point of contrast, the system running in the TAD demo has both MPD and RAAT. The Roon Ready implementation was chosen for the demos, with MPD as a backup.
I am pretty sure that the folks at TAD would not have stood for anything but the best playback they could get for their main demo at CES, so this should be some kind of testimony.
Again, this is exactly why we did not want an untested beta circulated.
This is an unpleasant, confusing situation for the user community to have to confront and what we are trying to avoid with the Roon Ready program.
As Rob wrote above, we put a proof-of-concept Roon installation on the BDP beta firmware track, so we could test out in our excitement at CES.
We did it this way because our developer was not at CES and few users are on the beta track, but it is clear now that this was a mistake… It was pretty clear on the very first listen that there was something wrong and that this wasn’t something to share, but unfortunately, some of you have used what is not at all up to the quality of what we expect our Roon Ready integration will be.
This firmware is nothing like what will ship and is clearly not representative of what Roon Ready can do as an audio delivery mechanism and Bryston did not intend for anyone to get the idea that we were officially Roon Ready at that point.
Sorry for the misunderstandings.
So, know that we’re still working on it! Roon Ready certification requires a lot more than just accepting audio. We are impressed with what Roon is, does, and how it sounds on our hardware. That’s why we were interested in partnering to begin with.
Great news, Gary, and thanks for the clarification.
Thanks everybody for the valuable information in this thread. This will surely help me make a decision.
Carmen, I thought I’d mention that it is possible to use Roon now with a BDP by enabling Squeezebox Support (Beta) in Roon and Squeezelite on the BDP. Sound quality is excellent, but, I’m guessing, not quite as good as it will be with RAAT because of the circuitous path.
It’s not as good, in my experience. And, another issue for me: gapless playback. With Squeezelite, I can hear a brief tick between gapless tracks. It’s subtle, but it’s there and I noticed it right away, because I am used to MPD playback with my BDP which is flawless.