Sean - first, you caught a mistake I made! Sorry. It is PSA, not MQA, that has made no committment. Going back and changing that now, so I don’t lead anyone else astray.
More after that…
Thanks Steve. Agreed, PSA have made no commitments to a timeline. Actually no one has. So I’m not sure where the expectation of days (as opposed to weeks or months) came from.
But I could have easily have missed it.
We gotta keep things accurate otherwise expectations spiral out of control and people get upset.
Again, I want this just as bad as others but I was told a while ago that it would take some time, so I’ve since relaxed all of my expectations considerably and am less anxious.
Sean - I don’t want to mislead anyone either. But honestly, I’m not sure where I got that impression from. Could be in this thread even. But likely over a the PSA forum. What I recall was that the extra work to get Roon passing MQA successfully to Bridge II was a matter of days. Heck, it could have been a week, though I don’t recall it being so specific. As I recall - but could be wrong - it was Dennis (apparently no longer with PSA) who stated that.
I’m sure the post can be found with a little digging (assuming it’s not been retroactively altered). Though also - as I recall - that statement was made very shortly after PSA getting the notification from Roon that MQA working with Roon was going to require a Bridge II firmware update. So that projection could have been made before they had time to really understand how big/small a job it was.
Frankly, if we assume my recollection is correct, IMO that still does not mean PSA should stop everything and do it. Heck, I feel bad for them, because they got this bad news just as they were prepared to issue the MQA supporting Bridge II update. So I’m sure they’ve got other priorities to get back to now. And are likely disappointed to have learned that their update was not going to help a large part of their customer base.
So my suggestion to post is not to suggest that it should/will be done quickly. That’s for PSA to prioritize. When I’m busy, I hate it when my wife comes to me with some task she just discovered that she wants my attention to; urgently. This is no different for PSA. They were supposed to the finished with Bridge II updates now. Then they got the bad news…
IMO we just need to let them know that this is something a lot of people care about. That’ll help them prioritize this unexpected bit of work appropriately.
Hi Steve,
I have been following this closely and I think there’s a misunderstanding. There wasn’t any mention of an update coming in days - only that the Roon SDK would be released in days to partners, to start work.
I’m not sure what bad news PSA got either? Actually we’re lucky that Roon released the SDK recently because if it came later (there was never a timeline given) we’d all be waiting a heck of a lot longer for any progress.
But I agree that would we should be asking the question for an update, directly to PSA, in the PSA forum thread that you linked. Hopefully Paul can shine some light.
If they can’t give a timeline, I hope they can at least give an update of the current status.
I actually think they did promise that an update was coming soon. I now worry that since PSA is coming out with their own streamlining device that support for Roon will go away at some point. While he has not said so directly, if you read Paul’s posts on the subject you could read between the lines to come to this conclusion.
Sean - we’re going to have to agree to disagree. I’ve been following this VERY closely myself, and I know I saw that statement. Granted, saying so without backing it up with the post doesn’t hold a lot of weight. But I know what I read.
And the bad news for PSA was that MQA working for Roon was going to require an update. That news came from Roon Labs a day or so before PSA released their last Bridge II update. Which is unfortunate, as PSA might have been unaware of their forthcoming Bridge II update would not work with Roon. If so - that they learned about it when the new RAAT API was announced (a day or so before Bridge II release) - the news could have been disappointing.
Gosh, I hope not! Roon RAAT support was a LARGE part of why I bought a DSJ. Without that I’d have purchased something else. But I would be real surprised if they don’t continue that support. They seem like a great company.
The sense that I got (and maybe this is just me) was that there may be no support for Roon in future versions but that Roon will continue to be supported in older versions of the Bridge II software or that there will be a Bridge III that will support the new PSA streamer but not Roon. Since Dennis is now gone from PSA and he was a frequent poster here we may never know or at least not for a while.
No, it’s not just you John… I’ve been reading between the lines too, and while I chose to hope your reading of the tea leaves is not correct, I can see where you might come to suspect that. Between the forthcoming streamer, many of the things you see said about Roon on the PSA forum, and the fact that they really didn’t want to provide MQA support in the first place, it adds up to being a little anxious to see this change actually happen.
And back to the time necessary to make this change… as an ex-programmer, with just enough understanding of that RAAT API to be dangerous, it’s my suspicion that changing the source code for this change will take far less effort than the time/effort to recompile, distribute, communicate and supporting the update, if/when it happens, for there will be certainly a large wave of support requests to follow it.
Don’t get me wrong here. I am really okay if PSA goes their own way. As long as Roon is supported under a version of software that works for me then I am ok if their path moves forward without Roon in the future. They are certainly allowed to develop their own streamer and support it over supporting Roon. As one of the Roon faithful I am okay with whatever they do as long as the version I have today works and I then never upgrade. I just won’t be buying their streamer the same as I don’t buy Aurender or Lumin just to name a few. I have no need for that kind of dedicated hardware while this is working so well for me. I have a dedicated QNAP TVS-471 that only does Roon. I am good for now.
Hi Steve, yes we have to respectfully agree to disagree - I don’t see where the expectation for an update within days comes from (this thread or the PSA relevant threads).
However I certainly agree with you and John - I too am worried that Roon support for the Bridge II will take a back seat to Octave at some point.
It would have been nice for the PSA and Roon marriage to carry on years into the sunset but it seems PSA want to tackle Roon head on, in terms of software and UX anyway. More power to them for having the courage I guess.
What we really need is Roon support for Qobuz, so we can get 192/24 FLAC and forget MQA completely.
Qobuz is only available in limited territories, unlike Tidal, it is almost worldwide. Putting a new streaming service requires extensive collaboration and integration and this takes time. I understand the negative reaction toward MQA and most of us are waiting for Roon to incorporate the decoding function into it.
Signing up for Qobuz from the US is trivial - it takes about 5 minutes to install and setup VPN software, and to sign up for a Qobuz account using PayPal.
After that, uninstall the VPN software and stream away, up to 192/24 FLAC. It works well and sounds excellent using BubbleUPnP, in the absence of Roon.
I had a discussion on PS Audio’s site regarding this topic. You can read it here: http://www.psaudio.com/forum/directstream-all-about-it/is-roon-support-going-to-be-eol/.
Based on information provided by Paul McGowan, Directstream Jr. (Bridge II) and Roon will continue. There are no plans to stop support and/or development moving forward.
PS Audio is coming out with new products and a new bridge (Bridge III) which will not support Roon and will support Octave which is their new streaming product.
I personally which they would build their new products to integrate with Roon. I for one believe the most important part of any audio solution is your music collection. And management of the music collection is key.
Thanks for that Bryan. Great news indeed! And what I would hope from PS Audio…
I’m personally at a loss as to why Roon has not totally decimated that market for streaming products in general. That vendors still continue to release stand alone music libraries, with their own streaming, and their own, custom user experience/management interface. It just blows my mind.
I’m guessing they look and decide Roon has not captured the market yet, and until they do, the vendors want a piece of that pie.
Thanks for posting! 
I agree with you 100%. To me Roon is the new standard followed by Sooloos and that gap isn’t close. I used Sooloos for years and couldn’t believe how much better Roon is.
Keep up the great work Roon. I’m a lifer. 
But Paul from PSA says he believes they can do a better sounding solution with the BIII and Octave (their upcoming server) than Roon as they will control both server and DAC. Whilst they probably can I am sure it won’t come cheap.
Jumbuck, thanks for posting that. I saw that too, and was baffled. Either it’s marketing BS, or there’s something I don’t understand. Given that I understand little about such audio streaming protocols (though I have professional background in true real-time networking), I know just enough to think I know what’s going on… and be wrong. Here’s what I think I know.
The server - be it Roon or be it PSA - is sending point to point packets across a shared network. Those packets may - or may not - have collision or other transmission problems (RFI and such) that require any given packet to be retransmitted. That vulnerability requires the packet receiver (in PSA’s case, the DAC - in Roon’s case, an endpoint) to have a buffer. It AIN’T real-time - what is sent in the audio stream is NOT received in real-time by the receiver. Or at least not always. So, it’s buffered to ameliorate problems in transmission. Now the part that I am REAL fuzzy on…
That implies that the there should be challenges in clock synchronization between the server and the receiver (DAC). And that matters because clock drift = jitter. But Roon’s core communicating with a Roon end point is NO different in these challenges than PSA server and DAC. They both have to tackle the tandem challenges of audio transmission over a less than perfect network: retransmission and clock synchronization. I cannot imagine where PSA owning both the server and the DAC is in ANY way different than the challenges of the Roon core communication with the Roon endpoint. So without knowing more, this sounds like marketing BS to me.
HAPPY to have someone explain to me why it’s a different equation for PSA.
Thanks.
For Psaudio maybe it’s a closed system…if that’s the case then you are held to ransom by their tech.
Thanks Wiz. Can you please clarify on what you mean by a “closed system”?
If you mean a dedicated connection between the PSA server and the PSA DAC, then you can do the same exact thing with Roon, in theory. That means - of course - the Roon core being dual homed, having one NIC to get control input, and one NIC to communicate with the server.
While I don’t know if that’s even possible now with Roon, it can’t be hard. And PSA would have to have the same challenge - short of all control input being physically on the device itself… direct connected touch screens and such.