That was copy and paste issue here but in Terminal both arm64 installed properly
Yes HQPlayer server mentions below with 5.1.7:
2025/10/19 16:20:49 NAA output requested format not available!
+ 2025/10/19 16:20:38 NAA output network engine starting...
% 2025/10/19 16:20:38 NAA output requested format not available!
! 2025/10/19 16:20:48 NAA output clNetEngine::PushPCM(): engine not ready
! 2025/10/19 16:20:48 clHQPlayerEngine::Execute(): push to FIFO failed
2025/10/19 16:20:48 Stop request (reset)
& 2025/10/19 16:20:48 Stop...
With nothing else changed on HQPlayer server side and just installing 5.0.1 on DietPi ODroid C4, it works fine.
Any clues with that info @jussi_laako ?
I’ll PM you and @jussi_laako a google drive .txt file with this output - too big to even copy and paste here
Interestingly just tried NAA OS image v5.1.7 (latest) for RPi4 and same issue…
Output is 8ch to Focsurite 18i20 Scarlet 3rd Gen (for 8ch DSP crossover)
NAA v5.0.1 no issue at all for many months, but anything newer has this issue.
So makes me think it is not DietPi if NAA OS having same issue @jussi_laako
Question is what could have changed from 5.0.1 to affect Focusrite support?
To further narrow down the NAA build that is the issue, 5.0.2-61 also works, but 5.1.0-63 and newer fails
This is on DietPi bookworm. I can’t find NAA OS v5.0 to test because they are not available
Tested latest HQP OS also, 5.1.2 and same issue - hqplayer-embedded-5.15.2-raspberrypi4-holored
So something has changed with NAA after v5.0.2 to break Focusrite compatibility
I think I have this model myself. But it is in storage and not connected anywhere at the moment. So at least I can check at some point…
(I just got it in the past to check if Focusrite would support automatic input rate switching, but they don’t)
1 Like
When you get to it, please share some photos of this infamous storage 
There’s some vintage products in there it seems !
Hi Jussi, what’s the current most economic sample rate switching method.
Hi guys, now I have the opportunity to check out the Everesolo DMP-A6, as a good friend of mine are going to sell his for further upgrade. To by-pass any questions, possibly questioning the choice, the purpose is to simplify Spotify playback for my wife and make one (1) standard playback route for the rig, except my HQPlayer source.
Is it possible to install/operate the HQplayer NAA on the Eversolo O/S?
Unfortunately it’s not possible at all, Eversolo is Android based …
1 Like
Thanks! After trial I returned the device, it does not qualify in my rig. Getting hard to find anything new, and it is a blessing as the price for nothing is attractive … 
1 Like
Hi @jussi_laako,
I run an HQPEmbedded server → NAA/HoloRed → Intona → DAC200 (USB @ DSD1024).
For many many months I have been using NAA via RoPieee OS on the Holo Red. It has worked flawlessly, at least since an issue with CM4 was resolved last year. I use default buffer time of 0.
Yesterday I decided to try the NAA517 OS image on the Red instead of RoPieee. It functioned normally, except I started to hear those small dust pops that are always strong indicators of USB packet drops. With default buffer time = 0. I started playing around with increased buffer time and that mitigated it but I never spent enough time tuning it to get it to go away completely - I just went back to RoPieee and it works flawlessly again.
So bizarre and surprising. Obviously, the NAA OS should perform just as well, if not better, out of the box. Subjectively, I was expecting to hear no difference at all of course, particular with the Intona inline.
What do you think it could be? Is the hardware default buffer on the Red via NAA OS not good enough for DSD1024 or something?
For me it has been working fine with Spring 3. My first question always in such cases is about status of 802.3x in the network. Because resends due to lost ethernet packets tend to cause I/O overload on such small ARM devices.
Similar problem used to appear in particular on RPi5 (and on RPi3 before) already at DSD512, but for me it has disappeared for RPi5 on latest NAA OS release.
I know it is counter intuitive, but you could try with smaller buffer time settings. Try for example 10 ms. Many have found 20 ms to help on sMS-200. Going too low however will start creating drop-outs due to buffer underruns though.
I noticed dropouts as well with 5.1.7 NAA
I’m using a Holo Red with Jussi’s image and default just always worked on prior releases. I found 50ms to be the sweet spot on the latest release. I also needed to drop blocks per cycle down to 2.
I may just be back to an edge case with DSD512 though, or my EtherREGEN is causing latency issues (haven’t tested that theory yet)
Thanks for corroborating. Not just my setup then. NAA 5.1.7 on my UP Gateway works fine. Between this and Intona incompatibilities, RPi CM4 USB seems to be a little temperamental in general.
This should only impact HQPlayer performance, not NAA per se.
Reverted to NAA 5.1.6 and so far it seems to be more stable using default buffer (I was on 5.1.5 before upgrading to 5.1.7)
@jussi_laako did anything change from NAA 5.1.5 / 5.1.6 to 5.1.7 that could be impacting performance on RPi CM4 USB?
It will certainly cause some challenges…
These are OS updates with things like wider native DSD support for some newer DACs. And some CVE security fixes.
I think I may have solved my issue. Looks like mine was related to FIFO buffer (rather than hardware buffer)
Short buffer (grayed not checked) with hardware buffer on default seems to be very stable. As always YMMV
1 Like
Sounds like your issue was at the HQServer layer, not NAA/HoloRed. Glad you solved it.
1 Like
I’m getting frustrated with the MacOS updates. Once again after installing the latest MacOS update, HQPlayer is not able to find NAA. I checked that this time the Local Network access is enabled, re-installed HQPlayer, but still not able to find NAA. What to try next?