Just the way @Deric_Chan said… Your NAA PC likely doesn’t have USB device side hardware, unless it happens to be one of my recommended devices having such.
I don’t understand what is the issue with RPi4 though, it is also simplest to set up.
1 Like
Perhaps get a rpi5 if you want fiber optic. I also have emi/rf shield and passive super caps here if you are like me ocd about noise
Cheers
As a long-time user of virtual audio interfaces / virtual cables on both Windows and macOS, I have a somewhat different perspective on this topic.
Virtual audio interfaces are deeply integrated with OS-level audio services: on macOS, for example, virtual devices are part of the CoreAudio framework. They are very reliable, low-latency, and straightforward to work with. You can see many professional audio users depending on it, and HQPlayer Desktop can fully utilize these virtual interfaces for both input and output. As a result, when running on a Mac, you generally don’t need to worry about complex internal audio routing to feed HQPlayer Desktop.
Windows, unfortunately, tells a very different story. Microsoft has never provided professional-grade, native OS-level audio services comparable to CoreAudio. It largely relies on third-party solutions, and the lack of solid OS-level support often leads to sync problems, latency issues, dropouts, or other instabilities.
For instance, I needed proper multichannel support, but VB-Cable’s “multichannel” implementation is really just multiple stereo pairs, so I gave up on it. The other alternative is VAC. While VAC does support multichannel, 8 channels appears to be the practical limit for reliable performance. Beyond that, audio quality and stability are no longer guaranteed. In my own tests, I was never able to achieve stable 12-channel audio relay to HQPlayer Desktop—buffering and clocking issues kept appearing.
So, in my opinion:
-
If you’re running HQPlayer Desktop on macOS → congratulations, you’re very unlikely to face these headaches. CoreAudio makes it easy to route audio from virtually any source directly to HQPlayer.
-
If you’re on Windows → unfortunately, the native OS audio support simply isn’t robust enough for demanding virtual cable / virtual interface use cases. In my experience, the most reliable solution is to use an NAA as the input device. Given the limitations of Windows audio architecture, this remains the safest and most consistent approach.
On Linux, ALSA’s aloop module can theoretically serve as a virtual interface for feeding HQPlayer, but I haven’t had the motivation to test it seriously. (My Linux HQPlayer Embedded machine is dedicated to DSP with synchronous audio I/O, so virtual routing isn’t part of my workflow.)
1 Like
Thanks for sharing your insights, your very good explanation (the only one) and the PM… Interesting how different things are in different minds.
I will test the linked virtual cable suggestion from Jussi, to see if there is anything meeting my expectations. If not, it will fail.
Since there is no interest (votes on Spotify link) on this forum in my thread for incorporating Spotify in the HQP playback of services, there will be no leverage on Spotify for opening my suggested option. The virtual cable was a way to become service provider independent. Perhaps not desired, as there might be kick-backs from service providers for the customer base HQP offer? It will fail, too, probably.
If it is just a Windows thing and most HQP users are MAC or Linux users and have it already fixed in the O/S, it will probably not be a viable option and thus fail.
Again, thanks for explaining in a very good way the reasons for not going there. 
If I may, can I PM you directly for any questions I might have? You have been helping me out in another case, If I remember correctly? It seems better than drawing un-necessary attention to topics and become laughing stock.
Sure let’s move to PM 
1 Like