Does that “crackling” also happen with the original HOLO Software??
No, not on my system with the Holo Audio May.
1 Like
Happy to hear that, also not on mine…
Currently I’m using (without crackling) RedOS from Holo Audio directly with Roon (I2S) and Jussi’s NAA image (USB) installed on a RPi4.
Since Harry changed to a new realtime kernel, I can’t use Ropieee without crackling on my Red.
Not tested yet DietPi or some other distributions with the Red.
1 Like
Unfortunately, after thinking that this 2024.03 release had fixed the issue, I still have occasional - once per minute? - ‘dust pops’ (same as ‘crackles’?) using high rate DSD 1024 into NAA on RoPieee. I don’t know if it’s exactly the same issue as @Burkhardt_Petermann but it definitely became a problem with 2024.02. This is on a Holo Red. Very likely related to kernel changes.
Based on discussion/history with NAA and @jussi_laako, I am 99% sure it’s dropped packets somewhere. I used to think it was on the output/usb side but some further digging/research makes me think it’s on the inbound side/nic. NAA uses UDP afaik and I don’t think the dropped packets are being recovered. Likely being dropped off the end of NIC ringQueue if kernel can’t grab them quick enough. (irq config?)
I don’t have this problem when using NAA OS image directly so I know it’s RoPieee. NAA OS uses its own realtime kernel. If I could ssh into RoPieee I could simply look at the ethernet stats for dropped/errant packets but it’s hard to diagnose without any tools/access.
No, the audio stream is over TCP. Only discovery is over multicast (UDP).
Hmmm ok thanks for your input. That would effectively close off my most recent theory. And so I am back to wondering if the RoPieee kernel changes are causing issues with scheduling/packet delivery on the outbound/usb interface.
If you have any clicks or other problems there are two likely sources:
- USB packet loss (sounds like a dust particle on a vinyl)
- Network stall (sounds like a small piece of audio missing)
These two can be possibly linked if 802.3x Flow Control is not active on the network.
NAA v5 protocol makes (2) less likely, even if 802.3x doesn’t work. But this is still something you’d want to avoid because packet loss means plenty of redundant network activity which just makes situation worse.
Yes, it definitely sounds like a dust particle on vinyl. Can you expand on how network stalls on the inbound side, assuming all packet loss is recovered via tcp, could cause packet loss on the USB output side?
There is only one switch in my path, an unmanaged TP-link switch with 802.3x built in. And fyi RoPieee is running NAA v5 now.
CPU and the local bus can get overloaded with the traffic + packet loss resends on the network side leading to congestion on the local bus and packet loss on the USB side.
But so far this has been seen mostly on certain other SoC architectures. But do not expect small low power ARM CPUs to be able to handle gigabit network speeds without functional 802.3x… Even for example iMac with i9-9900K CPU actively uses 802.3x when available (based on smart switch statistics)!
This doesn’t mean though that this would be the root cause in this case. It could be something else too. I just wanted to point out the most usual case for problems.
So first check your network setup, If it is based on good unmanaged switches, then you are usually fine by default (check switch specs for 802.3x). If you have managed switches in play, it is about 50/50 likelihood that you need to adjust the configuration. So “smart” switches are certainly all but smart out of the box, such need active configuration and maintenance (firmware updates).
1 Like
Mmh, I don’t really understand the argumentation.
With the same switch and network cable I’ve connected at the moment a Red and a RPi4 to the same DAC (Holo Audio May).
Red with Ropieee (using as NAA client or as Roon endpoint) is crackling (like dusty vinyl). Red with Red OS is not crackling using as NAA client or Roon Endpoint.
RPi4 with Jussi’s NAA OS is not crackling and also not with Ropieee.
My used RPI4 has only 1 GB RAM included (the RED IMHO 2 GB) and otherwise they should perform in the same way.
So, where could be the differences?
I suspect they are on RoPieee’s side. That’s the only thing I can think of right now.
Unfortunately I don’t have a Red to have a look. However, I could prepare a beta build for you so you can send me feedback to have a closer look. It also brings the 6.6 kernel, so that might make a difference as well.
Let me know if you’re willing to go down that path.
Thanks
Hello Harry, yes, we can give them a try, but I can start testing not before monday.
Ok great!
I’ll prepare a release during the weekend and let you know before Monday.
Thanks
Hi Harry, I would be happy to try the beta on my Red as well and provide feedback. I will be away as of Monday afternoon but can try this weekend if you can run a build. Appreciate your efforts.
1 Like
Thanks, will try it today.
Sent feedback. 86cb716da8b908d1. There were a couple of dustpops while playing song prior to/during feedback.
My feeback: a3416a3708a6e340
No changes in crackling (perhaps a bit more than before). Tested now using the Roon bridge with I2S out, but it’s the same with USB out and NAA.
hmmm…
The annoying part is that my own CM4 died (or the IO board did).
Anyways, I’ve just ordered a new set, so I can have a closer look.