Enjoy it 
Sync issues aside itâs a great device and rock solid when cabled in my experience.
Thanks @Engaged_Audio_Video - my impression is that Support wonât look at this further until the update (which I guess I can understand) but the more info the better.
did you try removing Switch B from the first chain, using the Node2 in Wifi mode?
Thanks Paul.
I think there may be some confusion here that I want to address. We donât assume that every partner will always run the latest version of RAAT, nor is there an assumption that every device on the network is running the same version. We provide the version number to help troubleshoot in a support context. RAAT is designed to be backwards compatible, and the system is quite forgiving in this regard.
After we first looked into these reports, we made a number of improvements targeted at tighter synchronization. Those improvements have been available to all partners for well over six months now. RAAT updates are generally not required for compatibility or stability â just for new functionality or endpoint-specific performance improvements.
Partners and devices going through certification more recently already enjoy the benefits of these changes, and most others have issued firmware updates that incorporate them. Weâre hopeful these reports are resolved for Bluesound devices once they release the firmware update they are currently testing.
Point being, this isnât a case of us having unrealistic expectations or being unable to make improvements or changes. RAAT updates are generally minor and device specific. They are also much less frequent than the regular improvements that happen in Roon. Roon interoperates with RAAT SDK versions going back to the very first releases in 2015.
Partner firmware updates take time, and our partners own their own schedule and QA process â thatâs one reason why we rarely rely on RAAT updates as a mechanism for improving Roon. This Bluesound grouping issue is a rare example of a case where the changes must happen at the endpoint. Point being, If you are unhappy about how quick it is rolling out, please make sure youâre letting them know as well.
Another test result:
PowerNode2 <> Switch A <> Primary Switch <> Switch B <> Bryston BDP-Pi = no evident syncing issues.
While none of this is conclusive, the Node2 is becoming more suspicious. On the flip side, why that particular model would act differently from the rest is truly weird and unlikely.
Good to know. Thanks for clarifying.
@woodford, thatâs a good call, are you thinking it could be something to do with the wired ethernet on the Node? Iâll also try to rig something up to test this out as it might isolate the problem at least.
Agreed. I think this would be an appropiate place to do so: https://helpdesk.bluesound.com/discussions/viewtopic.php?f=4&t=4305&start=10
Indeed - I started that thread but have never found Bluesoundâs responses very forthcomingâŚ
Yeah I agree. Although I understand that itâs very hard (and generally not wise) to comment on release timelines, a little bit more feedback on the matter couldnât harm themâŚ
[EDIT: hopefully the 6 March release will fix the syncing problem]
PerhapsâŚitâs a bit unclear and I donât really understand how the RAAT releases work. However, given that Bluesound have stated it wonât include the MQA implementation, I presume at best it would be updated to the most recent RAAT prior to thisâŚmaybe depends when the Roon fixes were rolled into RAAT?
Iâm unclear too. I had thought that the MQA issue was in Bluesoundâs court, but Bluesound have stated Roon readiness on Pulse Flex that their next release will be
âŚmostly updates, but not MQA. After Brian releases an update for that we will have the ability to test, but for right now we are waiting.
Does this mean that solutions are proceeding and weâre into testing phase (I hope) or not?
Iâve asked Bluesound tooâŚ
Brian
Well, I guess what theyâre waiting on is Roonâs forthcoming MQA first unfold implementation, rather than the pass-through implementation from last summerâŚthat seems to be whatâs being implied in their follow-up msg. Not knowing how it all fits together though itâs hard to say for sure.
Yes, I had thought they only (!) had to upgrade the RAAT protocol and, as the bluesound kit is MQA capable, the rest would follow. When I get a clear answer from Bluesound Iâll post it here.
Brian
I can shed some light. First, MQAâ
There are two parts to MQA support:
The first involves the stuff we made available in July. This change allowed Roon to âsniffâ streams for MQA content and provide appropriate information to downstream Roon Ready devices about the streamâs technical details.
There is a second part, which relates to our upcoming release of MQA core decoding support in Roon. The primary difference with the second part is that it fully fleshes out the details of putting MQA information in Signal Path. Newer updates of Roon will be capable of sending a decoded MQA Core stream to devices, which creates an additional test case to confirm working. I expect that this is why they were waiting for an update, however, I do not think they should be waiting now, since this update was made available to their technical team early last week.
Anywaysâlast July, we were still pretty far from reaching the commercial agreement with MQA that recently allowed us to begin development of more comprehensive MQA support, but we had received some technical information from MQA that would allow us to âsniffâ for MQA content + pass on the extracted information to Roon Ready devices. This information was conveyed to us informally as a courtesy to help us get Roon Ready partners up and running as soon as possible. We received that information around the beginning of June, and that is what triggered the SDK release in July.
From our perspective, these two parts are totally independent and were intended for separate release by partners.
As for the other issues, Iâm aware of three that seem specific to Bluesound:
The first is likely to be mitigated or fixed by updating the RAAT SDK. We made some fixes in the SDK related to synchronization last spring and are hopeful that those changes will address the issue as they have for some other devices. We have of course not been able to confirm this for sure. Unfortunately, when development/release/test cycles stretch out this long, it can be hard to be certain.
The second issue was fixed in July of last year. It theoretically impacts all Roon Ready devices running earlier SDK versions, but at a very low probability levelâwe were only ever able to reproduce it on networks with multiple Roon cores running/logged in at once.
The third issue was pretty evasive. We had one user who could reproduce it after only an hour or two and I was working closely with him for a while. At one point, I spent several days running stress tests and it happened for me once. After that exercise, I provided Bluesound with a detailed analysis. A few weeks later, I accidentally discovered a way to trigger the same crash much more reliably. More information was handed off to Bluesound, and a little while later they reported that they had tracked down the problem.
â
I hope this update helped shed some light. We are definitely not ignoring this, and Bluesoundâs technical team has been cooperative and responsive through the process with us, too. I think things are just taking a little bit longer than we would all like them to.
Yes it has, and thank you.
Many thanks, Brian, for bringing some much needed clarity to this discussion. I guess weâll sit back and hope that things now progress in a timely manner.
Thanks a lot for clarifying!
Appreciate your efforts here! Thank you.
Appreciate your efforts too. Thank you!
