What from the outside may seem like a trivial task does in fact require a serious amount of development and testing to implement and quality check. Please don’t confuse those private zones that list as ‘RoonSpeaker’ as true fully functional RoonSpeakers.
There are many that want RoonSpeaker implemented … but none as much as the Roon guys themselves. If it had have been possible then it would have been done already … unfortunately this is not the case and the realities of product development, resource availability and time scale apply.
Glad you’ve got a work-a-round during the interim.
In some ways having Roon core running on a headless unit that is hardwired directly to the main sound system isn’t a problem (all other systems can then be driven as remotes), but I wonder if it meaningfully changes the system requirements for that headless unit? Would you suddenly want a more powerful processor and more RAM that you would otherwise have put into that headless machine?
Stephan, I wouldn’t expect so. The core will always be handling any DSP requirements, the only “additional” burden would be the difference between output to an audio device on the core as compared to, say, a network zone. There will be people using Meridian and Airplay zones at the moment who can tell us their experience, but that doesn’t sound to me like a spec breaking difference.
@gmt Now that’s not strictly true is it? RoonSpeakers is already released and working, it is in the audio path of my MacMini acting as a remote client. I fully appreciate the staggered release of RoonSpeakers to all and sundry, not much point doing that unless there are apps to control it on other hardware.
We aren’t artificially holding this stuff back in order to time things better or “stagger” releases.
An early prototype of RoonSpeakers was snapshotted and used to implement private zones. This was done in a fairly quick way shortly prior to the 1.0 release because it was a feature that we thought was important to launch with. Back in the beginning of this year, the RoonSpeakers code was working well enough to satisfy that simple, constrained use case. That doesn’t equate to a suite of standalone RoonSpeakers apps for the various platforms waiting in the wings.
While the protocol is relatively mature, the implementation of the “real RoonSpeakers” that’s coming later this year is quite different under the hood. It has been re-implemented in a way that’s friendly to hardware manufacturers, lighter-weight for mobile platforms and embedded devices, and in a way that allows for future evolution in a world where many different companies are managing slightly different implementations. Most of this work is not directly related to streaming audio, but it’s still required to release that stuff.
Anyways, like everything else. When it’s ready, it will be released. We appreciate your patience
Thanks @brian for the explanation, I understand, if the audio stream is the fuel, then it’s the mechanics that are being tinkered with to deliver it to different engines
Right, now “A” way for an iPad “remote control” is to install Roon running on a “machine” connected to an USB DAC with music stored on a SSD. Alternatively, a Newtwork Attached Storage.
A certified Roon endpoint, or whatever it’s called, is designed to preserve fidelity by keeping noise out of the “system.”
I simplified this a ton, but there really is lots of hard work and thought put into this concept of Roon Core, Roon Remote and Roon Speakers. Call it R^3.
