HQ Player, Allo USBridge Signature and Dietpi

I have a new Allo USBridge and I am having a few issues with pops and crackles during music playback. I have been liaising with Allo directly over on the Audiophile Style forums. Basically the pops and crackles appear to be in place when I use HQ Player, which is on my desktop PC, with ROCK installed on an Intel NUC i7 and music installed on a Synology NAS. The endpoint is connected via Ethernet to the USBridge Sig and then onto a Mytek Liberty DAC. I upsample using HQ Player to DSD 256. This set-up worked with my older original USBridge.

If I stop using HQ Player and set-up an endpoint direct from Roon, and then use Roon to upsample to DSD 256 instead, then the pops and crackles go away. If I use volumio or ropieee but I don’t upsample, there are also no pops and crackles.

It appears that Allo has had feedback, as there is a note on their web page, saying some USB dacs have observed dropouts issue in 4.19.y kernel and have made available a Dietpi OS image based on kernel 4.14.92 for testing. Using this updated (back-dated??) kernel does help but some pops and crackles are still evident. There was also a suggestion on the forums (DIYAudio.com) to set the clock speed of the rpi in the USBridge via ssh, which I have tried also but to unclear results.

Yesterday Allo thought it may be an issue of streaming through Ethernet, however I tested with an Anker USB 3.0 to gigabit Ethernet adapter, unfortunately the same pops/crackles still exist.

Allo have now said that Roon and HQ Player may have a difference in data transfer rate and the size may be different while streaming, they have asked me to test different Buffer time settings in HQ Player.

Does @jussi_laako, or indeed anyone else, have any thoughts about this? Shall i just try the different settings and see?? Am I missing anything? Is there anything else to try?

What kind of network infrastructure do you have? Having proper support for 802.3x flow control is essential with many small devices that cannot handle network traffic at full speed.

The issue you describe has been existing in plain RasPi at least with models 1 and 2, and possibly with 3 also. This is because Ethernet interface is on shared USB bus with the on-board USB type A connector causing bandwidth issues. However, it doesn’t exist when using the I2S interface to a DAC instead (such as HifiBerry). Earlier RasPi models have just been designed too much to a price point at the cost of performance and quality.

RasPi 4 is supposed to fix this issue by utilizing the Ethernet interface built into the SoC instead of USB connected one.

You can use “ethtool -a eth0” to see flow control status for interface “eth0”, like in my case:

Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on

Thanks Jussi for the quick reply.

From a hardware point of few (and in addition to the kit mentioned in my first post), I use gigabit Ethernet switches, two 16 port Netgear (GS116UK) switches, connected via Cat6a Ethernet cables across the house.

I was aware of the shared bus issue, Ethernet/usb on the rpi 3 however I do not know if it still exists with the raspberry pi compute module in the USBridge Signature, maybe @allo.com or @rahulkc_s could comment.

I just tried this (from 0 - 4) and kept on getting ‘cannot get device pause settings: Operation not support’ messages.

Would the use of HQPlayer across a Network be much different to Roon upscaling across the same Network? Will buffer time adjustments make any difference as Allo are suggesting?

Are those smart/managed switches? If so, please check that the 802.3x flow control is enabled in the settings…

Maybe the functionality is not supported. You could also check if kernel “dmesg” output has any hints about this. In case of my workstation there is:

[ 31.221611] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Well, you could try USB straight from your Desktop PC (your HQPlayer machine, if I’m following correctly) to the Liberty DAC. One of the issues with your setup is that the Roon Core machine has to copy the raw PCM bits over the Ethernet to the PC, and the PC expands them into DSD and copies that right back onto the Ethernet. If the switches and ports are fast enough, this should work, but it would certainly be better if you could eliminate one of those legs (say, by doing the upsampling in Roon, or by eliminating the USBridge).

In general, audio takes a very little bandwidth for modern gigabit ethernet. I have setup like that, and can play 8 channels of DSD256 that way (1/10th of gigabit connection). It works even over WiFi here.

Networked converters like Merging Horus and Hapi are used in studios for recording music as well.

Problem are more for small devices their small network packet buffers (small number of ethernet frames) and that without jumbo-frames, ethernet packets arrive at high frequency due to their relatively small 1.5 kilobyte size. This can overwhelm interrupt handling capacity of a small CPU. It is not helped by the fact that the small CPU is often married with a cheap and simple ethernet interface that doesn’t have much hardware offloading capabilities.

You can see similar challenges also with some consumer internet router/firewalls. They may have gigabit ports towards internet, but few can actually handle full gigabit worth of traffic between internet and internal network.

They are unmanaged switches, i need to investigate further around 802.3x, as its not immediately obvious. In theory, although I am not sure about the USBridge Sig, everything is gigabit Ethernet.

I ran the command and got the following, I can’t see anything about Flow Control.

image

Thanks for the idea. I had this set-up working with the previous USBridge without this issue, upscaling to DSD 256 no problem. It will work with Roon upscaling, but not HQ Player however it appears that this maybe a network issue somewhere although it needs more investigation.

I did try changing the buffer times in HQ Player last night with 5ms, and I have set it to 10ms now. Although I end up going a little crazy listening for the pops and crackles, I am not sure I heard many, possibly none, when set to 5ms, but I do need to listen more. This was based on about 30 mins testing last night.

I tested for a couple of hours last night. Here are my results.

I listened to predominately to PCM content upscaled via HQ Player to DSD 256 with a buffer setting of 10ms. This generally played well, I did not hear many (for certain) pops or cracks over a few hours listening, which was pleasing. I did then try some DSD content, so DSD 64, 128, 256 still upscaling to DSD 256 via HQ Player. This would not play, it jumps rather than pops or crackles over the top of the music. I then tested DSD content, again DSD 64,128 and 256 scaling to DSD 64, 128 and 256. I could play DSD 64 scaled to DSD 64 and DSD 64 upscaled to DSD 128, every other combination jumps with gaps in the music. Out of interest, I did try the same test connecting to Ethernet over USB however I had exactly the same result, so I am not sure where the limitation is for this issue.

So, perhaps the work-around for now is to stick with DietPi_v6.18_41492_RPi-ARMv7-Stretch_AlloGUI.img and leave the 10ms buffer in place for now. I will test further and see if I hear any pops or crackles. I don’t have much DSD content, so ultimately, I don’t see that being a major problem.

I would however like a long term solution ideally.

This is just due to your CPU not being able to keep up with the processing demand. So not related to your NAA…

NAA doesn’t know if the DSD256 it gets originates from PCM or DSD…

Thanks helpful, thanks @jussi_laako. I assume you need something quite beefy then, I am running an overclocked i7 9700 @ 5ghz. I know the poly-sinc-ext2 is a heavy load, I bumped down to poly-sinc-mp, but it made no difference.

Filters don’t apply to DSD rate conversion. Only modulator does, and the SDM settings in “DSD Sources” dialog. But it mostly depends on the modulator selection.

On Allo devices, you need to update the Asix driver yourself to remove these pops and cracks. See doc here: http://3.230.113.73:9011/Allocom/USBridgeSig/info.
Step by step below:
1-ssh or terminal login using OS credentials
2-“cd /usr/src”
3-“sudo wget [http://3.230.113.73:9011/Allocom/USBridgeSig/install.sh
4-“sh install.sh” (Had to type “sudo sh install.sh”)