Dropouts - HQPlayer NAA endpoint running on a SOtM SMS-200 Neo

Audio Gear Talk HQ Player
1

I am having a very similar problem with an HQPlayer NAA endpoint running on a SOtM SMS-200 Neo. In my case the disconnects are every half hour on wireless or every 4 hours on wired to a Netgear router. It seems to be something to do do with the DHCP IP address lease renewal. Setting addresses to static is not making any difference. There is still some kind of DHCP lease renewal logic going on that is causing endpoint lease renewal to fail and resulting in endpoints being disconnected by the DHCP server.

I would really like to know what the Pi4 resolution is as my SOtM case sounds so similar.

2

There must be something wrong in your network setting … how do you set the fixed ip? With a reservation (using the device MAC address) on the router dhcp settings or do you set a fixed IP address in the device configuration ( must be an ip address in the not dhcp managed interval of the router)?

3

It’s very limited what can be done with a consumer unmanaged router as far as I can see. I started with the ISP’s Icotera i6800. Nothing can be changed there. So I asked the ISP to put the Icotera into bridged mode and bought a Netgear RAX20 AX1800.

The NAA has a an option of “DHCP” or “Static” mode, so . . .

Attempt 1
I put the NAA into Static mode with an address outside the managed pool of the router’s DHCP server. DHCP ignored this instruction and assigned the NAA a dynamic address anyway.

Attempt 2
Again I put the NAA into Static mode with an address outside the managed pool of the DHCP server. This time I “reserved” the address on the Netgear router and this was assigned to the NAA.

However I don’t think “reserving” an address is the same as assigning a static address. The problem is that this is the only option available on a consumer unmanaged Netgear router. The DHCP server just seems to end up managing both its “pool” and any reserved addresses as well. I guess what is happening is that the NAA believes it has a static address, doesn’t request a lease renewal and eventually the DHCP server terminates the lease and the connection is dropped.

4

What do you mean here?

You want to try NAA OS on your RPi4?

5

Some context.

This topic has been moved (at my request) from another similar thread describing similar symptoms with Ropiee, I assume on a RPi4.

I have been battling with this issue ever since we moved and at the same time moved ISP’s. The regularity of the drop outs is pointing to a possible DHCP lease handling issue. Anyone experiencing something similar in any environment may give me a clue to what a fix might be.

For the moment I don’t have an RPi4 to see if I can replicate the issue. I ordered a Pi2AES about 2 months ago to do precisely that. But I am not based in the US, I am based in Denmark. At the moment it is stuck in customs at Copenhagen airport because it arrived with no shipping documents and the Danish customs do not know what it is or what customs taxes are due. The rules here are rather strict and there are only 10 working days allowed for this sort of dispute to be handled before the goods are shipped back to the sender. I rather suspect this is what has happened although I have no confirmation.

So I may or may not source an RPi4 locally but I am rather sick of the whole business TBH. But that is not what this thread is about. I am asking if anyone has had similar DHCP lease handling issues and what they did about it.

6

My 2 cents - these dropouts are a pain in the butt to resolve! I think (think, hope, pray) that mine are resolved. In the end it was primarily a networking issue. Not exactly a DHCP lease renewal issue, but I suspected that early on. When I timed the dropouts I proved to myself it wasn’t as exactly on the same interval as I thought it was. Here’s what I went through, maybe it’ll be helpful resolving your issue:

Setup (before I started debugging my dropout issue):
Roon and HQPlayer running on 2018 i5 Mac Mini. Streaming Qobuz/Tidal. Mixture of RopieeeXL and and NAA OS endpoints. Netgear Orbi mesh wifi (3 nodes: 1 router, 2 satellites). Mac Mini runs wirelessly on the network. My office where I listen is across the house from the Mac Mini, meaning that my NAA endpoints are wirelessly connected to a different mesh node than the Mac Mini.

Back Story:
Roon has run on the Mac Mini for >1yr with no issues, both “bit-perfect” streaming and Roon up sampling to PCM / DSD. Super stable and happy. When I added HQPlayer I immediately started having dropout issues while streaming HQPlayer. It wasn’t obvious that the dropouts were network related. I was learning HQPlayer, and learning the limits of my Mac Mini for filter / modulator settings. I had a huge jumbled mess of CPU limitations and Network limitations. I sorted out the CPU limitations by buying a stack of long ethernet cables and putting EVERYTHING on a hardline. This made my HQPlayer streaming rock solid. Based on this I knew the root cause was network.

Debugging the Network:
An observation I had: DSD256 would stream fine (very few if any dropouts), but 16x PCM (32bit/768kHz) would have dropouts. A little quick math indicated at least partially where this was coming from: DSD256 has a lower data rate than 32/768 PCM (if you work through the math it turns out DSD512 has the same data rate as 32/768). So running PCM had more dropouts not because of computational difficulty, but because of higher network traffic. Basically I was operating at the edge of the bandwidth my network could reliably sustain for HQPlayer with other typical wireless network traffic.

On paper I drew out the path a “audio” packet would have to travel through my system to reach my endpoint: internet modem -(e)-> router -(w)-> satellite 1 -(w)-> mac mini -(w)-> satellite 1 -(w)-> router -(w)-> satellite 2 -(w)-> NAA endpoint. All wireless traffic, gotta love mesh networking. It was a huge mess of traffic. No wonder a relatively small increase of data rate was causing a noticeable increase in dropouts.

To clean this up I moved satellites around such that all of the network traffic stayed within a single satellite: internet modem -(e)-> router -(w)-> satellite 1 -(w)-> mac mini -(w)-> satellite 1 -(w)-> NAA endpoint. Essentially eliminating a hop back through the central mesh router. This made a big difference, getting me down to 1 dropout every 1 - 2 hours. But I would still get them. And if the wireless traffic in my house picked up (ie kids watching Roku) I would get constant dropouts making it unlistenable.

I realized that the ideal fix would be to get the Mac Mini hardwired into the same switch as the NAA end point. But due to house placement limitations (and limits to my wife’s patience for running long ethernet cables), I couldn’t do this. So I took the opposite strategy, and put as many other things on ethernet that I could (Rokus, smart TVs, work laptop, etc), such that the Mac Mini became the primary user of the Wifi in that part of my house. (The ethernet connections are into a mesh node, so still relatively heavy wireless backhaul traffic, but so far that has enough bandwidth to not become another weak point.) Essentially giving the Mac Mini unobstructed use of the WiFi, other than basic mobile devices, which typically are not significant enough to cause a glitch.

With this I got down to just 1 dropout every 3 - 6 hours. Generally stable, and not a problem. BUT I’m an OCD MF, and this wasn’t good enough. My suspicion was that my mac mini placement wasn’t ideal for WiFi signal, and I would get periodic wifi interruptions causing dropouts. Going back to my diagram above, there is still heavy wifi traffic in and out of the Mac Mini (concurrently stream in / up-sampled stream out). If that signal isn’t solid, there could be glitches. To clean this up I purchased an external WiFi adapter (actually several of them to get one I was happy with for the Mac Mini, gotta love Amazon return policy) that I could position with line-of-sight to the mesh node. This was the ultimate fix.

I’ve been rock solid ever since. No network dropouts (knock on wood). The final network path for my audio packets looks like: internet modem -(e)-> router -(w)-> satellite 1 -(w)-> Mac Mini -(w)-> satellite 1 -(e)-> NAA.

This solution is OBVIOUSLY very specific to my setup. But the idea that made a real difference is that the network traffic associated with HQPlayer is significant, and if it’s all running on WiFi you can easily hit a bandwidth limitation that causes periodic dropouts. If the HQPlayer can be hardline into the same switch as the NAA, it shouldn’t be an issue at all. But if that can’t be done, look for ways to improve wireless bandwidth available to HQPlayer.

wow, that got long… my bad…

2 Likes
7

Thanks for that, and what determination!

I have gone through a similar torturous process as you and have got the drop outs down to a very consistent 4 hours, plus or minus a few minutes. This is by using an internal Netgear router as the DHCP server and I see on various blogs that the default lease-time of a Netgear router is 8 hours but it might be hearsay and I cannot confirm. Using just my ISP’s router the drop outs are about every hour and the ISP tells me their lease time for some inexplicable reason is 2 hours. That I can confirm. So, on the face of it, it is possible there is some kind of correlation with the lease half time.

As you say there are a hundred and one things that have an effect so it is not just one magic bullet. I have made countless incremental network configuration changes to get to this point. The reality is our home network must support up to 30 devices, not just roon/NAA so there are a lot of dependencies. Segmenting the network with various switches certainly helped. The root cause probably does have something to do with the combination of network traffic and the relatively simple consumer infrastructure.

But on a whim after seeing it mentioned in several posts I have just enabled the IGMP proxy on my Netgear router and got to 5 hours without a drop out. As I understand it roon uses a multicast architecture (I don’t know about NAA) and IGMP optimizes multicast traffic by routing to unicast if possible. Fingers crossed when my next drop out is. The issue could have been IGMP all along. I wasn’t aware that our house move was in effect to a non-IGMP environment, or what the significance of that was. In hindsight it is possible that we didn’t experience this instability in our previous home environment because IGMP was enabled by default for some reason.

It’s late now in Denmark but I will leave roon running overnight and report back. If I don’t have a drop out by the morning it might be something that helps others with similar symptoms.

1 Like
8

yeah, I feel you on this point. My wife and 3 kids run the wifi hard all day. This is where getting as many things on hardline Ethernet made a big difference. It freed up a lot of wifi bandwidth, and enabled multiple people to stream video music without glitching HQPlayer.

I’ve not seen this point before. It was disabled in my Orbi. Based on your comments here I enabled it. Maybe it’ll make further improvements for me? I’ll report back if it gets worse :rofl:

One more thing I do with my Mac, not sure if it makes that big of a difference, is I “nice” HQPlayer to -20, making it the highest priority application running on my Mac. Maybe a moot point given other app settings to keep it running in the foreground. But I started doing this early in my debug process and just stuck with it.

9

Well in my case enabling IGMP has had a dramatic effect. The symptom was that HQPlayer would drop the connection with NAA after about 4 hours. Then roon would “loose connection”, presumabaly because it can no longer see the USB DAC attached to NAA.

NAA has stayed up overnight so that is 12 hours plus which is the first time I have been able to do that.

But (always a but), roon had still stopped playing this morning although the NAA is up and continues to stay up meaning I can restart roon by simply pressing the play button rather than rebooting the NAA. When I try that, roon will only play for a few seconds before stopping (but the NAA remains up). So I had a look in task manager and find very high (bouncing around 100%) memory and CPU usage for the Windows Management Instrumentation (WMI) service.

So I restarted roon. Re-start and re-scan was really slow. What normally takes a few minutes on my core took almost 40 minutes. When roon finally restarts it will not play for more than a few seconds. So next I have re-booted the core entirely and now roon restart and rescan is normal and play is normal also (fingers crossed).

Is that a memory leak?

This is way beyond my paygrade but I checked the event viewer and found large numbers of WMI errors with probable cause:

Throttling Idle Tasks, refer to CIMOM regkey: ArbTaskMaxIdle

So I seem to have finally solved my network issues but because the network is finally stable I can see other (non-network?) stability issues when running a combination of roon, hqplayer, convolution, DSD upsampling for 12 hours plus on my i7/ 16GB core.

1 Like