Sorry but how do you run HQPlayer on DietPi!? Version number sounds like HQPlayer 4 Desktop.
Sorry, I guess I misunderstood the question. That version number is indeed of the Desktop app that Iām running on my Mac.
I donāt know how to find the current version of the NAA daemon.
It can be found from HQPlayer log file if necessary. But can you try with the DAC directly connected to your Mac to check if the same issue exists there?
Note that Piās prior to RasPi4 are known not to be suitable as NAAs for USB connected DACs. Pi3 works fine to I2S connected DACs such as HifiBerry up to 192k sampling rate.
This is the version: Signalyst Network Audio Daemon 3.5.5. Iāll try to connect the DAC directly.
Ok, no white noise when connecting to the DAC directly. At this point my opinion is that the problem is related to the NAA daemon. I came to this conclusion based on the fact that the DAC is capable of playing PCM768, so is the ALLO USBRIDGE Sig. player when playing with Roon. The only situation when this problem occurs is when the NAA daemon is being in charge. Do you have another opinion?
Hi Jussi, HQP for Mac 4.3.1 and Allo DietPi 6.26m1ā¦I will check NAA version later and report back. What Pi board are they using in the new USBridge Signature?
For comparison you could try my NAA image on plain RasPi4 and see how it goes. Or if you have spare PC, boot up my x64 NAA image there. But could be that the hardware + DietPi is not sufficient for this use case.
I donāt have any other Raspberry hardware. It is not related to DietPi. The same happens with Ropieee and with Gentoplayer.
What bugs me though is that Roon works flawlessly on the same hardware/software configuation. After all, the hard work is done on the desktop. Isnāt there any hope? Could you check my logs or something and see whatās different between the way Roon and NAA Daemon work on the Allo USBRIDGE Sig that causes NAA Daemon to run into trouble? Thank you.
First thing to check is that your switch supports 802.3x (flow control), and that it is enabled in case the switch is smart one. Then it would be good to check that it also becomes enabled at DietPi side for the ethernet interface.
But it is possible that thereās nothing much one can do. And at least RasPi3 and earlier are known to have problems because they have USB-attached network interface on the same USB bus as the USB connectors. A bit too much cost savingā¦
3.5.5 is also pretty old NAA package version. We are now at version 4.0.1ā¦
Iām not using the ethernet port. Iām using an USB WiFi dongle. Also, the same bandwidth is used by Roon (Iām guessing) and the playback is flawless. So no problem with the network speed.
Could you please provide me with information on how to update the NAA package on DietPi? Maybe this would solve the problem?
That still doesnāt mean it wouldnāt be a problem. Tarffic pattern on NAA is different from Roon RAAT.
You need to ask DietPi maintainer. I have never seen DietPi or Allo myself, so I cannot comment much on that.
Does HQPlayer log the eventual packet drops? Maybe we could check and see if speed is indeed a problem?
Maybe @Dan_Knight could help with this matter?
Typical known problem on RasPi hardware are lost USB microframes (125 Āµs) on USB Audio Class protocol which happens due to USB bus load pattern and the way hardware/OS stack handles it.
On some hardware this causes small ticks in the sound, like dust particles on vinyl. On some other DAC the symptoms may be different, depending on how the DAC handles such lost frames.
It is not visible to HQPlayer, it is handled at hardware and OS level. On lost packets, networking stacks do re-sends, but on bandwidth challenged hardware this just makes situation worse. For this reason some networking hardware have support for the flow control at hardware level which ensures that there are no lost packets between network interface and the CPU in case the bus between the two (or CPU) doesnāt manage to keep up.
If the lost packets are at the USB Audio Class level, thereās no help for that, because there are no resends or error correction.
Jussi, I think you have answered all mine and Sebastianās questions, so no need for me to provide info requested earlier. I knew I should have bought an UltraRendu and thatās what Iām going to doā¦ha ha!
So the fact that Roon RAAT doesnāt have a problem with PCM768 (on my configuration) suggets they handle the strem better or does their strem pattern require less bandwidth?
Again, this doesnāt seem to be the case since both Roon and NAA eventually send the stream through ALSA and, in the case of Roon, the strem arrives in good shape to the DAC.
I run HQP Desktop on Mac with ethernet to PI4 with Signalyst 4.01. naa image. I connect by usb to either a Hugo 2 or Mojo at 768k sinc-m lsn15 with only VERY FEW intermittent glitches. As I have mentioned before this sounds better than an mscaler with my Chord dacs.
A little update: Iāve managed to migrate to buster and then installed the latest version of the NAA daemon. Sadly, the problem persists. It seems like Iāll have to accept that I wonāt be able to play PCM768 with HQPlayer on my configuration. Thatās a shameā¦
1 Like
Please can you tell me about ābusterā? And instructions how. My static is not as prevalent as yours and this may get rid of the annoying millisecond volume dropouts. Thanks Sebastian
Well, the latest version of the NAA daemon only works with the buster version of DietPi.
You can change to buster by using this command:
nano /etc/apt/sources.list
Change āStretchā into āBusterā. Then update by:
apt-get update
Then you need to download the latest NAA by this command:
wget https://www.signalyst.eu/bins/naa/linux/buster/networkaudiod_4.0.1-44_armhf.deb
And then install by using this command:
dpkg -i networkaudiod_4.0.1-44_armhf.deb networkaudiod_4.0.1-44_armhf.deb
At least thatās what I did and now Iām running the latest version of NAA.
1 Like