I do trust you. Will not try this. Have to fix a solution like the one you propose. In your comment number two above, the problem is not the digital signal leads, they are as you say isolated by pulse transformer. But it is the power supply, there are no efficient enough onboard power supplies on these singel card computers, I am afraid. Further with a housing of acrylic, the circuitry lays wide open for airborn RFI.Here you will have to trust me, this is exactly what I do for a living, scrutinizing power supplies for utmost silence and stability. The biggest problem is that compared to analogue side, where low level signals almost without exception are balanced class A, the digital side have not yet understod that the hardest way to feed sensitive cicuitry is plus voltage to zero ground. You cannot get the plus voltage clean enough without decouple to zero ground and polluting it too. It is a no-go-system for audio for decades, but directly implemented from computer industry where it works just fine. The digital side of audio will according to me never be clean enough unless the analogue audio balanced power supply thinking is being implemented. Especially the DAC suffer from not having the ultra clean +Vref and Zero Ground -Vref, even if they are improving regulators year by year and locating buffers and regulators closer and closer to power consuming chip sets. IMHO this needs to be revised from ground up, in the future for the final step in digital music purity, except the ongoing continous improvement taking place for the DAC chip itself.
For remote Spotify, you could have loopback driver on the Spotify computer and NAA running there, which would allow HQPlayer to use such as input for processing.
That was a brilliant idea, it would do I presume with a RPi with RopieeeXL? It contains RoonBridge and supports Spotify Connect. It would then communicate with HQP computer over ethernet LAN?
Likely not so easy solution. You would need to configure audio loopback there which is not entirely trivial. I was more thinking along the lines of regular Windows or macOS running regular Spotify application (which can double as Spotify Connect of course).
But I’m running HQP Desktop on that Mac which makes it easy.
Yours solution with NAA as an input works nicely though, for someone with just one Embedded license. I haven’t done this though, so @Stefan_Andersson1 you’d need to get all the steps from Jussi for help on that process. I can’t help on that particular option sadly.
Thanks for posting this. I’m planning to switch the Spotify hifi once it’s released but just want to be setup beforehand. Took a few tries but finally got Blackhole to work. Spotify doesn’t have any output settings, so have to change in midi.
I have a Rpi running RoPieee XL (I also have a HiFi Berry Pro HAT with it).
If I understand what you are saying, if I use a MiniDSP USBStreamer between the RPi and my main computer (Windows PC running HQ Player Desktop) I can listen to Spotify and have HQP do upsampling/converting?
The flow would look like this:
RPi/HiFi Berry (optical cable) → MiniDSP USBStreamer (USB cable) → PC running HQPlayer Desktop
If I do this, then HQP will allow me to select the MiniDSP USBStreamer as the input?
Thank you in advance!
PS. I currently run HQPlayer 3. I assume that I need to upgrade to HQP4 to be able to do this. Am I correct?
Yes, it should work fine. I have not tested USBStreamer under anything else than Linux, but it should work pretty much the same under Windows and macOS too. You just need correct firmware version flashed there. MiniDSP provides multiple different firmware variants for the device.
This is because the device is not set to be clock slave but instead tries to have master clock meaning that the two clocks are out of sync and slip a sample every now and then. On Linux with my USBStreamer support I’m setting USBStreamer to be clock slave for inputs which is necessary to have pop-free input. I’m not sure if there’s a way to do similar setting on macOS or Windows…
You are doing this for me automatically with Embedded right? Because I have no pops these days with Embedded and I didn’t change anything in Linux regarding clock slave.
If that’s the case, then I will need to do it manually myself in macOS. I think in Audio MIDI it can be done.
PS: I think I’m the one the brought this pop issue on Embedded to you, when I discovered something funky happening with alsamixer each system boot. But you fixed it of course.
In AUDIO Midi, “Internal Clock” results in annoying pops and “TOSLink Clock” is clean sounding but I’m not sure if this result is completely opposite to what you would expect?
