Please help with streaming pauses

[earnmyturns]

When I had my Mini server wired to the same router as the Rendu, drop-outs still occurred. This tells me that the performance of the Apple router connected to the cable modem - the router in the listening room is setup as an extender - is still a factor even when everything *is* wired.

In my experience, Apple Airport works well in simple configurations, but is difficult to predict/control when you want to do something fancier. That's why I gave up on it when I started doing digital audio at home. I ditched my Airport router and extender, and I replaced them by a solid pure router (no wifi, Ubiquiti EdgeRouter PoE 5), and connected all my audio renderers (a microRendu and a Sonicorbiter SE) and servers to it with cat 6 and Linksys pro switches, as well as a separate pro quality wifi access point for the mobile devices I use to control play between the servers and the renderers. Zero issues, even as I moved from UPnP/DLNA on my NAS and MPD on the renderers to Roon Core on a Linux Intel NUC accessing the NAS with CIFS and streaming RAAT to the renderers. The key here is that the router does just basic routing, DHCP, address translation, and firewall, not all the mess of dealing with wifi in a crowded radio environment. My suspicion is that your extender gets so busy managing wifi connectivity that sometimes it runs out of cycles to actually route. Maybe it gets more choked over time because some memory leak (routers have operating systems, even if you don't see them, and operating systems have bugs), so power-cycling it fixes the issue temporarily.

 

I know these issues are frustrating, but the reality is that the simplest star network with everything wired except for your mobile devices is the best way.

[davide256]

Here is my update. (I was without digital for a few days as I traded my superb Metrum Menuet DAC in to my dealer for the even better Pavane - my gosh, this thing is incredible already with ~4 hours on it.)

 

The update is: I rebooted my Apple Wifi router and all problems disappeared. When I first started playing digital today the dropouts were worse than ever, even with very low CPU load on the server running HQPlayer. Per the other thread pointing at general network issues I unplugged the Apple Airport Extreme, which probably had not been bounced for a year or more, and all problems completely disappeared - I've had an hour+ of play with zero drops.

 

Sonore really needs to produce an mRendu update that allows a wired connect to the server in HQP mode. It's crazy to have to rely on the quality of your Wifi network for the thing to work.

 

I had no issues using HQPlayer through a gigabit switch to my hardwired mRendu as NAA.

[davide256]

I had no issues using HQPlayer through a gigabit switch to my hardwired mRendu as NAA.

 

As a point of clarification, in this setup I had both file server and mRendu off the switch, so that neither was forced to route traffic through the home router. A router connection to the switch is necessary for DHCP and wifi remote control of the mRendu.

[PaulF]

In my experience, Apple Airport works well in simple configurations, but is difficult to predict/control when you want to do something fancier. That's why I gave up on it when I started doing digital audio at home. I ditched my Airport router and extender, and I replaced them by a solid pure router (no wifi, Ubiquiti EdgeRouter PoE 5), and connected all my audio renderers (a microRendu and a Sonicorbiter SE) and servers to it with cat 6 and Linksys pro switches, as well as a separate pro quality wifi access point for the mobile devices I use to control play between the servers and the renderers. Zero issues, even as I moved from UPnP/DLNA on my NAS and MPD on the renderers to Roon Core on a Linux Intel NUC accessing the NAS with CIFS and streaming RAAT to the renderers. The key here is that the router does just basic routing, DHCP, address translation, and firewall, not all the mess of dealing with wifi in a crowded radio environment. My suspicion is that your extender gets so busy managing wifi connectivity that sometimes it runs out of cycles to actually route. Maybe it gets more choked over time because some memory leak (routers have operating systems, even if you don't see them, and operating systems have bugs), so power-cycling it fixes the issue temporarily

 

From where I'm sitting now, yes, I'm sure you're on to something there.

 

Now, again, after merely rebooting the Airport, I had over three hours of music last night with not one single drop out! So - the problem has become less pressing (too bad I was not smart enough to try that long ago - I did not guess that the main router could be affecting even a chained advice like that).

 

Redoing my whole network like you did is certainly a good idea, but it may be quite awhile before I get there.

 

However, before or instead of that, if the drops return (I'm sure they will), I will probably just reconfigure the extender and make it just a router, not a Wifi extender (disconnect it from the Wifi network). The Mini, of course, has its own Wifi support; I don't need the router to remote into it from the laptop I use to run it remotely.

 

In fact, thinking about it now, I have no idea why I connected the audio router to the Wifi network anyway. That adds no value.

[PaulF]

Sonore really needs to produce an mRendu update that allows a wired connect to the server in HQP mode. It's crazy to have to rely on the quality of your Wifi network for the thing to work.

 

I think this is clear now, but do let me retract my misguided statement here. The only problems that exist are caused by overly complex/wireless network setups which have nothing to do with the mRendu per se.

 

(Though I've been doing computer audio for 10+ years, I've only been doing networked computer audio for a month or two.)

[earnmyturns]

However, before or instead of that, if the drops return (I'm sure they will), I will probably just reconfigure the extender and make it just a router, not a Wifi extender (disconnect it from the Wifi network). The Mini, of course, has its own Wifi support; I don't need the router to remote into it from the laptop I use to run it remotely.

 

In fact, thinking about it now, I have no idea why I connected the audio router to the Wifi network anyway. That adds no value.

Sounds like you have a promising solution there!

[firedog]

There have been 2-3 others here (including me) who've had dropout and stuttering issues with the HQP NAA mode of the mR. I had the issues only in that mode, not the others.

 

Solved it by plugging both the mR and server into a switch and the switch into the router.

It may be that the protocols of the NAA software on the mR have some sort of network/communication issue that only effects a small minority of users.

 

Basically I did the same idea as davide256 above.

[PaulF]

So, I'm home today so I made the change suggested above: I "unhooked" my LinkSys extender from the (main) Wifi router (the Apple Airport), making it - just a router. With Eth cables to the Mini and the mRendu, there are no dropouts. I suspect the issue is now completely buried.

 

There was one aspect to this problem that kept me from looking more closely at the networking end initially, which is that the dropouts were definitely correlated to CPU usage on the server - or at least to playing DSD converted to PCM. When I play redbook upsampled to 352 Khz - like right now - CPU usage is very low. When converted DSD64 or 128 to PCM, however, it hovers around 60-80%, and the dropouts were far worse playing converted DSD. Ok, I'm not 100% certain about that, but it sure seemed that way.

 

How the server's CPU load is related to the router or overall network's packet load I could not say!

[wgscott]

If the server is OS X, Activity Monitor.app can help you pin down which processes are doing this (assuming you want to replicate/waste more time on this). It is essentially a GUI for unix top, but with a few added features. I also use the free app MenuMeters so I can keep an eye on the processes from the menu bar (a habit I developed when I had SGIs). It might be the CPU consumption goes up because of the network hand -- OS X is trying to re-establish the connection.

 

Anyway, glad you got it working.

[PaulF]

If the server is OS X, Activity Monitor.app can help you pin down which processes are doing this (assuming you want to replicate/waste more time on this). It is essentially a GUI for unix top, but with a few added features. I also use the free app MenuMeters so I can keep an eye on the processes from the menu bar (a habit I developed when I had SGIs). It might be the CPU consumption goes up because of the network hand -- OS X is trying to re-establish the connection.

 

Anyway, glad you got it working.

 

I was speaking about what Activity Monitor reports. That's where I'm getting my HQP CPU figures.

 

But HQP is all I'd been watching - if some other processes were also had increased load, I would not have noted that. That's entirely possible.

 

Anyway, all in the past now! All this because I mindlessly bought a Wifi Extender instead of the simpler router I should have.