Not sure if others have had this issue, but I can’t play Airplay (Shairport) on my RoPieeeXL Pi if HQPlayer NAA has been running. It LOOKS like it plays, and the device acts like the track is playing, but I get no sound.
if I quit HQPlayer (on the Mac where it resides), then RoPieeeXL Airplay will work normally.
It will also work if I start HQPlayer, but once HQPlayer has been running (via roon), then Airplay output is muted.
As a control group, I also have a RoPieee pi that does NOT employ HQP NAA, and there’s never an issue playing Airplay.
Any ideas? (I know, I can go to the HQP mac and quit HQP, but trying to avoid that workaround.)
(I don’t use Airplay all that often, but some apps, such as SiriusXM and Podcasts prefer that connection.)
HQPlayer NAA tends to open a pipe to the USB DAC and leave it open, blocking other services. I’ve had the same issue if I want to use NAA for playback, and then switch back to the Roon standard Bridge function for the same DAC. Often I have to cut power to the DAC to “break the spell” so to speak or maybe even reboot RopeeeXL.
It’s not actually true … as Jussi specified in another forum (AS), as long as the device is selected as active NAA (see attached screenshot) it won’t be available for anything else.
But there is no need to reboot or power cycle anything, you just need to select another NAA device and the other one will be released and will be available for other inputs.
If no other NAA device are available then you need to shutdown HQPlayer.
It could work the same as Roon does: it only releases device control whenever you don’t play anything for a certain amount of time (in Roon it’s 3 seconds I believe). And to be clear: not one of the other services would ‘grab’ control of the audio device unless you play via that service.
So I think that scenario would also work in your case.
Yeh agreed for HQP Desktop. That’s why you need Embedded ! Can be done by family from a phone/tablet web browser
Good to see you found a solution.
But does that mean you need to unplug/replug USB connection when switching from NAA to Airplay/Spotify?
A more elegant solution is to pipe Airplay and Spotify through HQPlayer itself…
Here I am piping an optical source (in this case bit perfect casting Amazon Music HD to WiiM Mini) into HQPlayer. This optical source could be anything. WiiM Mini supports Airplay2 and Spotify Connect.
Nope, my main Pi uses a Pi2AES HAT and I go AES/EBU from that to my Denafrips Pontus II DAC. The Airplay Pi just uses USB, so all anyone has to do is swap inputs on the DAC, easily done from the front panel.
It is released once you close HQPlayer. But when HQPlayer is running, it is using the DAC and knows it’s capabilities.
No, Roon is also holding the device. Even if it is not selected as active output zone. That’s why you need to disable any overlapping zones from Roon when using HQPlayer.
Roon just stops playing after some seconds, just like HQPlayer.
If the device is released, all state is lost and when it is rediscovered, it needs to be reconfigured and it may not be even the same device anymore (except with RME) so we cannot trust it’s capabilities which means it has GUI implications (selection of available sampling rates, etc).
For example if you are using ASIO driver, and switch between PCM and DSD output mode while not playing, the DAC switches immediately (in most cases). Same for output rate selection and such. You also get much less potential noises when starting playback because DAC is not potentially always switching between PCM and DSD modes for example.
In addition, starting playback is also much faster, when the whole thing doesn’t need to be reinitialized.