The folks on Audiophile Style are trying to get to the bottom of it as well. This is a lengthy response from Paul McGowan to Chris Connaker. My takeaway is that the Maestro Connector currently supports at least UPnP and Openhome and will fallback to simple HTTPS URL exchange if the endpoint supports that. Those are explicitly mentioned. He also makes the point that the Maestro approach is to support the native protocols of the streamer like Audirvanna or JRiver rather than requiring an additional software layer like roon ready.
Chris —
The sentence you quoted is doing the work badly, so let me say it plainly. “The computer” in it means a Mac or PC in your house. Not a tablet, not my servers.
Maestro is two pieces. The interface is delivered from the web, which is the part RichardSF describes as cloud-based, and it’s why updates land without a reinstall. The other piece is a native program called the Connector that you install on a Mac or PC (and soon a iPad or Android). The Connector holds your Qobuz session, opens the HTTPS connection to Qobuz, and decrypts the stream there, on that machine. It then serves the audio to your streamer over your own LAN. Nothing about the music touches my cloud, and nothing leaves your network unencrypted. My servers do accounts, metadata, and the control channel; they never carry audio. So no contractual problem, and no proxy in a remote control.
Now the part you called ambiguous, because it’s the part I actually care about.
When a streamer talks to Qobuz directly, its own little CPU does everything: the TLS handshake, the decryption of every packet, the HTTPS fetch across the internet with its stalls and retries, the buffering to cover them, and only then the audio. Those are hard, bursty jobs, and inside the box the audio clock and DAC are sitting next to the processor doing them. My argument, which you’re welcome to test with your own ears, is that a streamer sounds best when it does as little as possible: read a plain file off a fast, quiet local link and play it.
So Maestro’s Connector takes all of that off the streamer. The computer does the internet side, decrypts the stream, and serves your streamer a plain file over the LAN through the streamer’s own native path, UPnP or OpenHome, in the format the box asks for. The streamer isn’t proxied through anything exotic; it’s reading a local file, the way it would from a NAS. Same for your local library, which the Connector serves the same way.
That is also the answer on Roon. Roon Core does the same internet work on a computer, but it then re-wraps the audio into its own transport, RAAT, and asks the endpoint to run Roon’s software stack to receive it. It’s a fine system, and it’s why Roon Ready exists. I’m doing the opposite: no protocol of my own, the streamer’s own path, nothing added on the box. Audirvanaand JRiver are closer to me than Roon is; the difference there is what the app around it does, which is the part I’m still building, as Richard fairly says.
The upcoming iPad and Android apps are the same idea with the Connector built into the app instead of installed on a computer. The tablet holds the Qobuz session, does the internet side and the decryption, and hands the streamer a plain file over the LAN by the same native path; or, plugged into a DAC over USB, it is the player, and there’s no other box in the chain at all. What a phone or tablet can’t do is stay awake all night as a server for every room, because the operating systems put apps to sleep. So for a whole-house setup you’ll still want something that never sleeps: a computer today, and later a small always-on box built for nothing else. The mobile apps get you out of the “PC required” business for the listening you do in front of them.
Where a streamer can fetch an HTTPS URL fine on its own, Maestro can simply hand it the direct Qobuz link and step aside. And yes, today it needs an internet connection and a computer. Not a PWA.
I’d rather you tried it than took my word for any of this.
Paul
