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.