Roon should be the end all/be all with regards to audio playback throughout the house.
I think this is a good goal to have in mind–but it is not the goal of Roon as you’re using it today.
We have had many conversations about how to do this right. It requires high degrees of synchronization + low latency support–the latter is a capability that very few devices are able to meet, and usually only over ethernet. There are some WiFi solutions that are semi-low-latency within single manufacturer ecosystems. AES67+friends can do this over ethernet in mixed environments.
Generalized use cases for this include stuff like shipping TV audio around to speakers all over the house with lip sync. Today, this is mostly done using distribution amplifiers, and when done using networking (e.g. Dante), it is expensive and requires special hardware.
I think a mostly-pure software solution is possible…but stitching together a bunch of UPnP devices would not provide a good experience. You can’t do “ducking” if the audio device has a 10-30 second buffer delay. Nor can you work with many kinds of external sources.
We aren’t interested in “best effort” solutions that make bad experiences. It would be horrifying if Roon turned into Foobar–a loose confederation of extensions build by 100s of uncoordinated people that is just a total mess to use as a result. By avoiding that sort of complexity, we are able to bring music/audio experience to lots of people who won’t tolerate the mess/hassle.
Mess/hassle like this really isn’t opt-in, either. We’ve noticed that when we add complexity for the more technical users (even optional complexity), non-technical people come to this site and get absolutely snowed with those details by the technical guys, and walk away with their head spinning. People are thinking about things that they should never have to think about, because we exposed them to extra complexity. This is a tough line to walk, but one of the takeaways is: if we can’t do stuff in a really turnkey, smooth way, we probably shouldn’t do it.
That said–I’m not averse to adding an extension API that causes Roon to play a URL now, and possibly resume the previous audio afterwards. That’s something I’ve intended for us to do for a while, but just hasn’t bubbled up the schedule.
The other stuff–being a generalized audio sink, providing “audio routing fabric” for the home, etc, are things we’d like to explore in the future, but if we do it, it won’t be a band-aid, and we will probably prioritize a robust, modern solution over legacy concerns like including UPnP devices.
You can see in this thread that this is already failing–because I’m spending time guiding 3rd party developers and providing support to customers using this this UPnP extension. I’m here because our support team is tracking this stuff and bringing it to me, so they are spending time too. Somehow everything bubbles back to us even when it is “3rd party, unsupported”.
To the end customer on a Roon trial, they don’t really care who’s fault it is. We can still lose someone as a customer if this stuff doesn’t work well enough for them, and we are generally nice/responsive guys, so we engage. I’m not sure I want to expand this problem. It’s our job to keep the ecosystem around Roon simple, consistent, and easy to use.