Thanks for the explanation. I didn’t know that the volume control was implemented in the endpoint with pcm. I understand what you’re saying about the 90% not being able to run it due to weak servers and lousy network gear. And of course everyone will want to. It’s easier to just make it not available at all from a support position. However if implemented in a purpose built OEM system using powerful servers, and known network gear, I’m sure all of the compromises you mentioned could disappear. Perhaps it could be an OEM only option for OEM’s who are willing to use the hardware required to get the job done?
With HQP on a $600 Asrock desk mini and a $75 router I get non-existent lag with the volume control sending audio via NAA to my streamer.
If it was an option, if you clearly explained that a certain standard of hardware is required for smooth operation, I don’t think it should be considered a “hidden pitfall”. If you don’t have the gear to run it smooth, simply turn it off. You could have a warning that pops up and says no support will be provided if this feature doesn’t run smooth on your gear.
This is why we bundled quality network gear with our systems. Moving forward all networking gear will be built in our systems. There will be no option for end users to do things poorly. If they can press a power button, they will get 100% performance in any possible scenario. If they don’t, that means we failed not them. No excuses.