I and others have spoken about the desire for a “virtual audio device” feature, allowing other sources like Spotify to play through the Roon DSP and output channels, without any attempt to integrate UI. Ugly, but there are real-world needs.
I was thinking of my then-Windows 10 NUC.
But as I was looking at YouTube music channels, I remembered I now have a Nucleus. ROCK and Nucleus force a rethinking of this request. (Obviously the Roon team already understand this.) The virtual audio device is a software device and is internal to the computer where the Core is running, so it would allow a feed by other software running on that same computer. But ROCK and Nucleus do not allow installation of other software, and other Linux variants may not support your favorite music source.
Another example of old-think, single box rather than a networked architecture. I’m quick to criticize this in others. Mea culpa.
So to be practical we would need some form of networked architecture, where the source can be fed from another device.
First I was thinking of a USB input. But not all audio devices have USB out. HDMI on these boxes, does it support input? Anyway, many devices don’t have HDMI.
The Core obviously has a network port. This would be useful, the source machine could be anything, anywhere in the house. But there isn’t a good industry standard network protocol for feeding in music. Hmm.
But Roon has one: RAAT.
The obvious answer is to make the Roon remote implement the virtual input device, and feed it back to the Core using RAAT, and the Core does its thing and sends it out to the designated zone (maybe the same one it came from, maybe not), after doing DSP as required for the designated zone. Bidirectional RAAT — woohoo!
Of course it doesn’t have to be from a remote, a complete Roon on the Core server could do it all locally.
@Brian, does this make sense? Should be an afternoon of coding, right?