Yeah, that’s an inescapable engineering reality–there can only be one master clock during playback, and most devices don’t provide a way to make slight adjustments to their clock frequency, so during multi-zone RAAT playback, we choose one of the endpoints to be the master and the others must make adjustments to conform to it to it.
That fact that this reality exists doesn’t constitute an argument for or against this sort of integration, in my view. It’s just a fact of life that must be dealt with to engineer a multi-zone playback system that doesn’t support flexible clocking at the slaved endpoints.
My guess is: were this to happen, it would be because we expose an interface for DSP plugins, and HQPlayer slides into it. I don’t see any fundamental conflicts with this model. That said, in our view–HQPlayer’s primary value is in the DSP, not in its audio distribution support. Jussi’s point is that HQPlayer is actually both things, and I understand why that’s important to him. And I understand why you might want to combine his DSP with our audio distribution. I would like to see that sort of interoperability made possible in the future.