OK, so this is a fairly weird one. I have the following system:
(4) Allo Digione Signatures running on 8GB Raspberry Pi 4 - two headless, two with Raspberry Pi 7" touchscreen monitors.
(1) JustBoom DAC/Amp on a Raspberry Pi 4 8GB
Roon Core on Windows 10 - hardwired
Two Netgear unmanaged switches
Netgear NAS - hardwired, with bonded NICs
Here is what befuddles me. The first group of Allo Digiones run perfectly, never cut out. The JustBoom DAC/AMP shuts down the entire system when I add it. So I did some research. I have an ASUS RT-AX92U mesh network. If I run my ASUS bandwidth monitor when the JustBoom is in the system, I immediately get a bandwidth spike that reaches 120 MB/Second when I select a track, and then the entire Roon system shuts down. When I remove the JustBoom unit and start another track the bandwidth spike is only a max of around 75 MB/Second which my router has no problem with. This spike in both cases is almost entirely in the SSL/TLS process. So I think the problem is in the difference that the two setups implement the SSL/TLS security. I do not want to shut down SSL/TLS security, and I don’t want to throw out the JustBoom DAC/AMP. So do you have any suggestions? I’m am fairly new to Roon and love the sound. The system is still new enough to make major changes. Oh, BTW I have two unmanaged switches in the system, and ethernet connections between the core-router-NAS. And one of the Allo Digione Signatures is on wifi with no problem.
Thanks,
Mike
Have you tried swapping a justboom and digitone locations, to rule out any wifi network differences? You could also look in Roon’s advanced audio device setup to see if there’s any difference in buffer size (or anything else) which may cause a data spike.
Yes, that was one of my early troubleshooting steps. Both locations are on ethernet, but one location goes through a non-managed switch. I will check the buffer size - good idea.
I’m not understanding the SSL reference. Between what two things is the SSL socket? Roon doesn’t use encryption on the local network (last time I did a packet capture).
Have you asked the developer of Ropieee to check to see if it’s something obvious with the HAT that’s causing it? It would be my first port of call. He’s very helpful.
ipeverywhere Thanks IP! My understanding, far from comprehensive, is that Roon causes a bandwidth surge when it starts on a new track. This should be no problem on an internal network, but is it an issue when downloading from a streaming service like Tidal or Qobuz? I don’t understand if the ssl (secure sockets layer) or tls (transport layer security) are involved. All I can see on my monitoring tools is that the JustBoom endpoint causes a ssl/tls bandwidth surge when a track starts downloading and then the Roon endpoint disconnects. But there is much less of a ssl/tls bandwidth surge on the Allo DigiOnes (the ASUS RT-AX92U bandwidth monitor measures bandwidth for various protocols: DNS, general, http protocol over ssl/tls, let’s encrypt, msoft windows update, microsoft.com, ssl/tls, and www http). All the protocols bandwidth draws are minimal except for ssl/tls. The ssl/tls for JustBoom draws 120 MB/second while the same measurement for the Allo Digione Signature is only 75 MB/second. My available bandwidth tests out at 110-117 MB/second so the 120MB/s plays havoc with the router. These measurements have all been made while using Qobuz so I would think these would be WAN measurements. Do you know if ssl/tls is used on the Qobuz/Roon end of a connection? I may be going down a rabbit hole here, and any help would be gratefully appreciated.
*CrystalGipsy * I’m new to Roon and Ropieee and don’t really want to bother Henry. I always figure if I’m having a problem it is something that everyone has run into.
So I went into the Device Setup for the JustBoom Dac/Amp and cut back on the Max Sample Rate from 384 to 192, and the Max Bits per Sample from 32 to 24. The endpoint still pulls a lot of bandwidth when it starts up, but not enough to stop the system. And the sound is great. Thanks all for your help.