It’s an idea of chatgpt, but I don’t know if it’s working in his dark room 
Why not use USB connection? There are very few reasons to use I2S.
The reason is that in my setup the DI-25HE is used purely as a DDC and reclocker.
The current Eversolo T8 NAA implementation requires a USB connection to my Audio-GD R8HE Mk3 DAC only for the NAA handshake, while the actual audio is transmitted over HDMI I²S to the DI-25HE.
Unfortunately, a USB connection to the DI-25HE cannot be used because its Amanero interface does not provide the required USB 5V detection for the NAA handshake.
My question is therefore whether a Raspberry Pi with HQPlayer NAA and an Ian Canada TransportPi Digi II can output HDMI I²S directly to the DI-25HE without requiring any USB handshake at all.
I don’t know what USB handshake you are referring to and how it is related to this…
Device is never providing USB VBUS, instead it is the USB host who provides the VBUS to the device(s).
When you use USB connection to a DAC, there’s nothing to reclock though, as the asynchronous USB Audio Class as used by modern DACs is not passing any audio clocks.
I2S is like S/PDIF or AES/EBU on steroids, but with the same downsides as clocking resides at the wrong side of the connection (source).
Sorry, I probably explained it poorly.
I don’t mean the DI-25HE should provide USB VBUS.
What I mean is that the Eversolo T8 NAA currently only becomes operational when a USB DAC is connected. Without a USB DAC connected, the T8 does not output audio over HDMI I²S.
So my question is simply: would a Raspberry Pi running HQPlayer NAA with an Ian Canada TransportPi Digi II output HDMI I²S directly without requiring a USB DAC to be connected first?
That is strange indeed, I would contact Eversolo about that.
Possibly yes, at least my NAA implementation is not particularly bound to USB, except for DAC corrections. USB and other outputs are not related to each other either, but instead separate.
But you will likely get better technical performance by just using USB from RPi to the DAC.
Hi Jussi,
I wanted to let you know that I found the root cause of the issue.
The problem was not HQPlayer. I had accidentally flashed an older Amanero Linux firmware intended for a previous Combo384 revision onto my Audio-GD DI-25HE, which uses the newer IC40 Combo384 interface. This caused the USB interface to malfunction and resulted in the connection problems I experienced.
After restoring the correct IC40 firmware provided by Audio-GD (CPLD_1081_DSDSWAPPED + firmware_2006be11), everything is working again. HQPlayer is now streaming DSD512 to the DI-25HE without any issues.
Thank you again for your help and patience during the troubleshooting process.
Best regards,
Mario de Roos
1 Like
Hi Jussi_Laako,
Following up on my earlier posts in this thread, I have now completed my migration from the Eversolo T8 NAA to a Raspberry Pi 4 running DietPi with the Signalyst NAA Daemon.
Everything is now working perfectly, except for one remaining issue that I can consistently reproduce.
Current system:
• Roon Server: iMac 2020
• HQPlayer Desktop 6: Minisforum MS-A1 (Ryzen 9 7900)
• NAA: Raspberry Pi 4 (DietPi + Signalyst NAA Daemon)
• USB: Raspberry Pi → Audio-GD DI-25HE
• I²S (HDMI): DI-25HE → Audio-GD R8HE Mk3
HQPlayer settings:
• SDM output
• DSD512
• ASDM7ECv3
• poly-sinc-gauss-hires-lp
My configuration is fixed to a single output family:
adaptive_rate=“0”
auto_family=“0”
bitrate=“22579200”
So HQPlayer is permanently outputting DSD512 at 22.5792 MHz.
The problem:
Whenever I manually skip to the next track, or playback automatically advances to the next song, I hear a clearly audible high-frequency digital transient through my speakers.
It is NOT a mechanical relay click, but a short digital tick/pop.
I recorded the behaviour here:
What makes this interesting is that the output sample rate never changes. Everything remains fixed at DSD512.
I have already ruled out:
• Different NAA endpoints (Eversolo T8 and Raspberry Pi 4)
• Different USB cables
• Auto Rate Family ON/OFF
• Adaptive Rate ON/OFF
• Different Resync Delay values (50 ms, 500 ms and 2000 ms)
• Latest Amanero IC40 firmware
• Latest Audio-GD firmware
The behaviour is identical in every case.
The HQPlayer log consistently shows the following at every track transition:
End of track
Idle request
Stop request (tail)
NAA output network engine stopping…
…
NAA output network engine stopped
Playlist clear
Playlist add URI
Play
Playback engine running
NAA output network engine starting…
NAA output network engine started at: 22579200
To me it looks as if the NAA output engine is completely stopped and restarted between every track, even though the output remains fixed at DSD512.
Audio-GD has confirmed that the DI-25HE and R8HE do not use output mute relays, so any restart of the USB/NAA stream becomes directly audible.
My questions are:
- Is this stop/start behaviour of the NAA output engine expected?
- Is there any GUI setting, hidden configuration option or command-line parameter that keeps the NAA output engine continuously alive between tracks?
- Or is this simply the intended behaviour of HQPlayer Desktop?
Everything else in the system is working flawlessly, so I’m really curious whether this behaviour can be optimized.
Thank you very much for your time, and thank you again for the incredible work you’ve put into HQPlayer.
Greetings,
Mario
My A8 does that as well - and my T10. A glitch every 12 1/2 minutes, with DSD512 and PCM x64 only.
maybe the ram is full every 12,5 minutes and it glitches
Yes, that is what I am thinking about as well, a memory leak or a buffer overrun. It definitely is not related to my computer or network, but must be something between HQPlayer and Eversolo. As it is the same with the A8 and the T10, I can imagine that there is a problem with the NAA implementation of Eversolo or a communication problem between HQPlayer and Eversolo. Only happens with DSD512 and PCM x64.
This is one of the Roon “features”, but you can overcome it by setting “Idle time” in HQPlayer. I recommend something like 10 seconds to 30 seconds.
In latest release, HQPlayer now forces this automatically when Roon is used as a source.
This is quite bad. The DSD spec requires that the mute period is minimum 50 milliseconds across any data change. So mute must be engaged at least 25 milliseconds before any change and must hold for 25 past any change, before unmuting the output again.
So the DAC must have at least 25 milliseconds of look-ahead buffer so it can detect changes in advance.
Hello guys, I’m using a eversolo A6 master gen1 via NAA with these HQP settings:
filter 1x: poly-sinc-ext2-short
ASDM5EC fast
SDM bitrate limit: 44.1k x256
48x dsd option: disabled
adaptive rate: disabled
Everything works well except for 48k songs and above.
I’ve tried many “Filter Nx” and combination of settings but none of them could play. JPLAY waits 7 seconds then it skips to the next song. HQP writes “requested filter not possible with this rate combination 48000/11289600, stop”
AFAIK this eversolo doesn’t support 48k DSD. Is there any solution apart from changing the unit?
What if I would like to have only those songs played in PCM, for example? so it doesn’t just skip them entirely?
Thank you
This filter applies for source rates <= 50 kHz. And this is what the PDF manual says about it:
HQPlayer Client also shows largely same information on filter selection, but in more compact form.
So the filter can be used only for integer ratio upsampling. Hence no conversion between rate families and no downsampling.
Nx filter is then used for source rates above 50 kHz.
So I would recommend to just choose a filter that can manual / Client says can do any ratio. Closest to your current one is poly-sinc-ext2-medium.
I just wanted to give a shout-out to @ohcrapgorillas.
HQPTuner looks absolutely fantastic. It keeps everything that makes HQPlayer so powerful, but presents it i@ohcrapgorillas a much more intuitive and modern way. The filtering, logical grouping of settings, built-in explanations and prevention of invalid combinations make it far easier to experiment with HQPlayer’s huge DSP capabilities.
As someone who has been spending a lot of time comparing filters and modulators on an Eversolo T8 NAA setup, I can honestly say this is the first interface that makes HQPlayer feel approachable without taking away any of its power.
The only thing I find a bit disappointing is that HQPTuner is currently available only for HQPlayer Embedded. I use HQPlayer Desktop, and I would absolutely love to have this interface there as well. It would make everyday use and DSP experimentation so much more enjoyable.
Great work! I really hope this project continues to evolve. It would be wonderful to see ideas like these influence the future HQPlayer user experience as well.
3 Likes
Feature request (T10 / NAA mode): USB DAC identity passthrough for HQPlayer DAC Correction, plus a local now-playing metadata API
First, thank you Eversolo/Zidoo for shipping NAA support across the lineup. I run a T10 (firmware v1.1.60) as an HQPlayer Embedded 5.17.2 NAA endpoint, USB out to a Holo Audio May KTE, and the core streaming functionality works well. Two requests that would complete the integration:
- USB DAC identity passthrough (enables HQPlayer DAC Correction)
The T10’s NAA currently presents its USB output to HQPlayer as a generic device (“Eversolo:T10: USB DAC”). HQPlayer’s DAC Correction feature depends on the NAA endpoint forwarding the connected DAC’s USB identity and descriptor details back to the server. Behind a Signalyst-based NAA the same DAC is reported as “Holo Audio UAC2.0 Gen2” and HQPlayer offers the matching “Holo Audio Spring 3 / May” correction preset; behind the T10 the preset list is empty, because HQPlayer cannot identify the downstream DAC. Jussi Laako has indicated the HQPlayer/NAA-v6 side of DAC detection is already implemented and that corrections specifically require the endpoint to expose the USB device data. Request: forward the connected USB DAC’s vendor/product identity (and the descriptor detail the NAA v6 protocol supports) so DAC Corrections work through Eversolo endpoints. This would benefit every Eversolo owner running an external DAC over NAA, not just Holo owners.
- Local now-playing metadata API for external sessions
In NAA mode the display shows metadata when the HQPlayer source provides it, which is great. When Roon is the source, Roon sends HQPlayer no metadata (a Roon-side limitation), and the community has filled the gap with a proxy (RooNAA6) that injects Roon metadata into the NAA stream, which the T10 renders correctly, credit to your NAA metadata implementation. A cleaner long-term integration point: expose a documented local HTTP endpoint (the existing /api/device/playback surface is read-only) that allows setting now-playing metadata (title, artist, album, cover art) for the active external session. That would let integrations feed the display directly without in-path stream interception, and would serve Roon, LMS, and other ecosystems generically.
Happy to provide logs, packet captures, or beta testing on the T10. Thanks for considering.
1 Like
Hi @jussi_laako,
Eversolo has just released firmware v1.6.01 for the T8.
Do you know if anything has changed or been updated in Eversolo’s NAA implementation with this firmware?
Since Eversolo uses its own NAA implementation, is there any way from the HQPlayer side to see which NAA version/build the T8 is currently running, or whether it has changed after a firmware update?
Thanks!
Check the NAA version into the HQP log
Sorry no, I have not heard anything from them regarding this release.
You can see the version reported by the NAA module from HQPlayer log file.
