It doesn’t. If you’re streaming HQPlayer, you’re using HQPlayer all the way to the endpoint. There’s no loopback into Roon for distribution via other technologies.
There’s nothing fundamentally wrong with the idea of a loopback mechanism. I’d like to see it happen, but…
- The current approach can be implemented without major changes to Roon or HQPlayer.
- The interfaces currently exposed to us by HQPlayer aren’t sufficient to do loopback-style processing well.
- The current approach still feels necessary because it preserves the HQPlayer sound by allowing their engine to own as much of the playback process as possible.
NAA does not feel like a good solution for getting the stream back into Roon because it’s designed for playback, not as a DSP plugin interface. Roon needs to know the precise relationship between the concept of “time in the audio stream” and “time on the wall clock”–systems like NAA are almost certainly going to destroy this because they are not built around that set of constraints.
If we were going to do loopback, we’d want an interface in HQPlayer that was built for that purpose: something where it can take a stream, process, and return it to us simply without jury-rigging network protocols built for other purposes.
I’m hoping that this first round of integration will be a good first step between Roon + HQPlayer, and will establish confidence on both ends about our ability to work together and deliver product. Assuming this works out well, I don’t see why we shouldn’t want to do more in the future.