HQPlayer - wireless vs. wired

[jhwalker]

I have been using HQPlayer on either OS X (now macOS) or Windows for a couple of years now, but have never been able to get 100% reliable (i.e., hiccup / stuttering-free) performance until the last week or so.

 

I had been pursuing this issue at the desktop level - i.e., checking CPU utilization, memory usage, network utilization, etc. - with the expectation the stuttering was being caused by resource limitations on the HQPlayer computer. After all, everyone keeps talking about how resource-intensive the upsampling / DSD conversion process is, and how it requires a really high-end machine, etc. Frustratingly, no matter what I did (e.g., adding memory, changing from HDD to SDD, "optimizing" the OS, using different HQPlayer filters, using the -2s filter variants, moving from macOS to Windows, etc.), the stuttering continued - not continuous, and sometimes I'd get a few hours of trouble-free performance, but the stuttering would inevitably return

 

Last week, as part of my ongoing tinkering, I decided to take a closer look at my network - in particular, the way the traffic routes across the network end to end. And I discovered what could be a weakness: routing across my wireless "bridge".

 

You see, my Roon core (server) sits at one end of the room, very close to my wired network infrastructure (i.e., cable drop, cable modem, Cisco switch, etc.) and it is hard-wired to the network at that end of the room. My HQPlayer machine (and my mRendu + DAC) sits at the other end of the room, on the other side of an Apple Extreme-to-Apple Extreme wireless bridge (installed because I didn't want to run a 25' Ethernet cable across the room). The HQPlayer machine (an extra Toshiba i5 laptop I had sitting around) was connected *wirelessly* to the Apple Extreme at the *front* of the room (e.g., AE#1), so all traffic to / from the HQPlayer was coming 1) from the Roon core, 2) across the wireless bridge to HQPlayer for processing, 3) *back* to the AE#1 across the bridge, 4) back across the wireless bridge to AE#2 for 5) output to the mRendu (hard-wired to AE#2).

 

On a lark (literally, I woke up in the middle of the night and decided to give it a try), I decided to hard-wire the HQPlayer laptop to AE#2 to avoid the extra routing across the wireless bridge (i.e., once the Roon output gets to the back of the room, all the routing is now local) and, voilà! NO MORE STUTTERING. For a week now. I am now also able to drop the -2s variants and use the supposedly higher quality base filters with no issues whatsoever - the 2.8 GHz i5 laptop with only 8GB RAM is perfectly adequate for poly-sinc-short, DSD7 256 performance

 

Just wanted to share this experience for others who may be suffering from HQPlayer "stuttering" - it may not be your HQPlayer machine. Look at the system end-to-end - even if it appears your network is not overutilized (mine doesn't seem to be, the wireless signal is strong and bandwidth more than adequate), latency (or some other factor I'm not considering yet) may be a factor.

[jhwalker]

For comparison, I drew a quick diagram to show how the routing changed when going from wireless > wired on the HQPlayer machine:

[tboooe]

Glad you got it sorted!

 

Here is an idea to simplify your network more and perhaps even gain some improvement...connect the microrendu directly to your laptop. If you laptop does not have an extra network port, you can use a usb to ethernet adapter. Lots of people of expressed improvement doing it this way by eliminating the switch (AE #2).

[jhwalker]

Glad you got it sorted!

 

Here is an idea to simplify your network more and perhaps even gain some improvement...connect the microrendu directly to your laptop. If you laptop does not have an extra network port, you can use a usb to ethernet adapter. Lots of people of expressed improvement doing it this way by eliminating the switch (AE #2).

 

Yes, I've been reading that thread with great interest, as well

[lmitche]

I have been using HQPlayer on either OS X (now macOS) or Windows for a couple of years now, but have never been able to get 100% reliable (i.e., hiccup / stuttering-free) performance until the last week or so.

 

I had been pursuing this issue at the desktop level - i.e., checking CPU utilization, memory usage, network utilization, etc. - with the expectation the stuttering was being caused by resource limitations on the HQPlayer computer. After all, everyone keeps talking about how resource-intensive the upsampling / DSD conversion process is, and how it requires a really high-end machine, etc. Frustratingly, no matter what I did (e.g., adding memory, changing from HDD to SDD, "optimizing" the OS, using different HQPlayer filters, using the -2s filter variants, moving from macOS to Windows, etc.), the stuttering continued - not continuous, and sometimes I'd get a few hours of trouble-free performance, but the stuttering would inevitably return

 

Last week, as part of my ongoing tinkering, I decided to take a closer look at my network - in particular, the way the traffic routes across the network end to end. And I discovered what could be a weakness: routing across my wireless "bridge".

 

You see, my Roon core (server) sits at one end of the room, very close to my wired network infrastructure (i.e., cable drop, cable modem, Cisco switch, etc.) and it is hard-wired to the network at that end of the room. My HQPlayer machine (and my mRendu + DAC) sits at the other end of the room, on the other side of an Apple Extreme-to-Apple Extreme wireless bridge (installed because I didn't want to run a 25' Ethernet cable across the room). The HQPlayer machine (an extra Toshiba i5 laptop I had sitting around) was connected *wirelessly* to the Apple Extreme at the *front* of the room (e.g., AE#1), so all traffic to / from the HQPlayer was coming 1) from the Roon core, 2) across the wireless bridge to HQPlayer for processing, 3) *back* to the AE#1 across the bridge, 4) back across the wireless bridge to AE#2 for 5) output to the mRendu (hard-wired to AE#2).

 

On a lark (literally, I woke up in the middle of the night and decided to give it a try), I decided to hard-wire the HQPlayer laptop to AE#2 to avoid the extra routing across the wireless bridge (i.e., once the Roon output gets to the back of the room, all the routing is now local) and, voilà! NO MORE STUTTERING. For a week now. I am now also able to drop the -2s variants and use the supposedly higher quality base filters with no issues whatsoever - the 2.8 GHz i5 laptop with only 8GB RAM is perfectly adequate for poly-sinc-short, DSD7 256 performance

 

Just wanted to share this experience for others who may be suffering from HQPlayer "stuttering" - it may not be your HQPlayer machine. Look at the system end-to-end - even if it appears your network is not overutilized (mine doesn't seem to be, the wireless signal is strong and bandwidth more than adequate), latency (or some other factor I'm not considering yet) may be a factor.

This is a great explanation of a complex topic. I have had two machines directly connected through a bridge, transfer traffic back to a wireless router and then back through the bridge to the endpoint, so each packet between the two machines added two more packets to the router and back over a wifi connection.

 

No wonder stuttering is a result.

 

Ping does a good job of showing the path taken between two machines. From there routes can be added to fix problems.

[ckpiv]

This is very interesting as I have been having similar issues that have been driving me crazy trying to figure out the stuttering/dropouts. I have Roon/HQ Player on a Mac Pro Quad Core 32meg of ram which is wired to 8 port switch that is wired into my wireless router. I run the HQPlayer NAA on an old mac mini (mid 2010 dual core) feeding a ifi Micro iDSD which is wired into the 8 port switch.

 

The Mac Pro was only using around 17% load on the CPU's and the Mac Mini was only using around 8-10% but was still getting stuttering and dropouts. Replaced the switches, cables and the router and the problem continued. Everytime a dropout occurred I would check and could not see any spikes in CPU usage, network, drive access, etc.

 

Like you, "on a lark" I decided to try something completely different. I disconnected the mac mini from the switch and turned on wi-fi. Now there is not stuttering or dropouts! hmmmm. Went back to the mac mini and changed the ethernet of 100mbit plugged it back in and dropouts did improve over the 1000mbit service but they were still there. I'm now thinking the mac mini has a failing ethernet port. Going to pick up a usb ethernet adapter for the mac mini and see if that works. But you are right about looking at the system end to end. Everything matters.

 

But for now all is good, can upsample to DSD256 without issue and enjoy the music

[rickca]

I initially thought I'd need a wireless bridge when I got a micro rendu because the Windows 10 machine that hosts my music files is in a different room than my primary audio system. I was unable to find a range extender that didn't have awful reviews, so I decided to get a PCE-AC56 wireless card for the PC and move my RT-AC3100 router from the PC room to the audio room.

 

You can check the signal strength when planning such a move with something like Wifi Analyzer on an Android smartphone. Surprisingly, on 5GHz 802.11ac I still got between -55 and -45 dBm despite a couple of walls. I can still easily max out my 75/10 Mbps Comcast internet connection.

 

If your neighbors have Comcast-provided gateways, ask them to disable their Xfinity wifi home hotspot feature. It's enabled by default and they may not even know it exists. These networks (named xfinitywifi) just cause a lot of unnecessary contention on the available wifi channels.

 

A wireless bridge just isn't the best for reliability or efficient bandwidth utilization.

 

Avoiding wireless entirely is great but I live in a rental condo so wiring in-wall ethernet isn't an option.

At the time I thought the micro rendu had to be hard wired to a router or extender. Now of course we have this whole thread http://www.computeraudiophile.com/f10-music-servers/novel-way-massively-improve-sq-sms-200-and-microrendu-31110/index28.html

[jhwalker]

I initially thought I'd need a wireless bridge when I got a micro rendu because the Windows 10 machine that hosts my music files is in a different room than my primary audio system. I was unable to find a range extender that didn't have awful reviews, so I decided to get a PCE-AC56 wireless card for the PC and move my RT-AC3100 router from the PC room to the audio room.

 

You can check the signal strength when planning such a move with something like Wifi Analyzer on an Android smartphone. Surprisingly, on 5GHz 802.11ac I still got between -55 and -45 dBm despite a couple of walls. I can still easily max out my 75/10 Mbps Comcast internet connection.

 

If your neighbors have Comcast-provided gateways, ask them to disable their Xfinity wifi home hotspot feature. It's enabled by default and they may not even know it exists. These networks (named xfinitywifi) just cause a lot of unnecessary contention on the available wifi channels.

 

A wireless bridge just isn't the best for reliability or efficient bandwidth utilization.

 

Avoiding wireless entirely is great but I live in a rental condo so wiring in-wall ethernet isn't an option.

At the time I thought the micro rendu had to be hard wired to a router or extender. Now of course we have this whole thread http://www.computeraudiophile.com/f10-music-servers/novel-way-massively-improve-sq-sms-200-and-microrendu-31110/index28.html

 

I'm literally line-of-sight to my wireless router - 95% signal strength - and can max out @ 300Mbps on Internet downloads. Still not sufficient for the back and forth needed for DSD256 (25Mbps each way, total of 50Mbps through the Apple Extreme route), at least in my setup. Probably a bottleneck (AE processor?) somewhere along the way.

 

In any case, limiting the wireless portion of the signal to a max of 12.5Mbps (streaming PCM at 24/192) or 25Mbps (DSD256) one-way completely eliminated the stuttering

[Jud]

One way to tell where the problem is, if possible the way your system is set up, is to play HQPlayer directly from the computer it's installed on.

 

I did that and got stuttering, so I knew not to bother playing with my network.

 

A little while later I installed a slightly lighter weight Linux distro (Lubuntu in place of Xubuntu) and haven't had dropouts since.

 

 

Sent from my iPhone using Computer Audiophile