HQPlayer's Network Audio Adapter

[pkane2001]

New user here, please be gentle 

 

I'm trying to play DSD256 in my music room (basement) from another computer with attached RAID storage over Wi-Fi (in my office upstairs).

 

I have a MacBook Pro attached to the DAC over USB. HQPlayer runs on the MacBook Pro.  If I play content from MacBook hard disk converted to DSD256 (DoP), there are no problems -- plays well, no drop-outs, stuttering or any other ill effects. 

 

If the file is being served by the computer in the office with attached RAID and over WiFi, I get occasional drop-outs when outputting DSD256. I can understand that WiFi can be bandwidth or latency limited. Except that when I play the same files but output them to the DAC as PCM 384KHz, from the same remote storage, over the same WiFi, I get no drop-outs at all...?

 

This is the part that confuses me, as I would expect that the bits read from RAID and transferred over WiFi would be the same, regardless of how I output them to the DAC. Is this not so? MacBook is not CPU limited -- all cores are at about 50% or less when outputting DSD256.

 

WiFi connection is over 250Mb/s from basement to office, but latency might be an issue. So, I tried to set up NAA on the same MacBook Pro that runs HQPlayer, and used this to increase buffering to 250ms... This helped a bit (the drop outs are not as frequent) but still not perfect.

 

Any ideas, suggestions, things to test? I'm almost ready to pull CAT5 through the walls, but not quite there yet  

 

   -Paul

 

[pkane2001]

2 hours ago, pkane2001 said:

If the file is being served by the computer in the office with attached RAID and over WiFi, I get occasional drop-outs when outputting DSD256. I can understand that WiFi can be bandwidth or latency limited. Except that when I play the same files but output them to the DAC as PCM 384KHz, from the same remote storage, over the same WiFi, I get no drop-outs at all...?

One more data point: if I send DSD128 to the DAC, there are also no drop-outs. The problem appears only during DSD256 playback. Somehow it's more sensitive to my network (or RAID) limitations than DSD128 or PCM384k, even though the same music file is being transferred in all three cases. Why?

[pkane2001]

6 hours ago, arglebargle said:

@pkane2001 You say you tried switching the NAA to your mac laptop, can you clarify what the other NAA device is?

 

Well... it was the same Macbook laptop that HQPlayer was running on that was also connected to the DAC. My thinking was that NAA would allow me to turn on some level of buffering, while the Mac audio driver does not. It really seemed to improve things. Stuttering/drop outs went from being every few seconds to being every few minutes. Maybe larger buffer would help, but HQPlayer has a 250ms limit. 

 

I also tried to use another Mac laptop to run HQPlayer and keep NAA on the first one, connected to the DAC. This also seemed to work, but the result wasn't as good as running both on the same laptop. In this case, both Macs were using WiFi, and I assume the path from RAID storage to the DAC was a lot more tortured, resulting in two trips over WiFi compared to only one in the first scenario.

 

Thank you for you comment, @arglebargle! I'll look into a WiFi amplifier/repeater or even an external antenna to see if this will improve things. Although I would think that a repeater might add more latency of the system.

 

 

 

[pkane2001]

On 3/30/2017 at 7:37 AM, pkane2001 said:

Thank you for you comment, @arglebargle! I'll look into a WiFi amplifier/repeater or even an external antenna to see if this will improve things. Although I would think that a repeater might add more latency of the system.

 

So I did try a WiFi repeater. Flashed my old router with DD-WRT and set it up as a bridge with ethernet output to the laptop feeding the DAC. Much improved performance, but still, I observed the following:

 

1. All files up to (but not including) 192/24bit FLAC appear to play with no issues over the WiFi link

2. 192/24 files use up about 6-7Mb/s bandwidth with occasional jumps to 10, while 44/16 stays under 1Mb/s

3. 192/24 files still experience occasional drop-outs, although these are now much more rare, every 5-10 minutes

 

At this point, I have to assume that this has to do with latency, since I have plenty of bandwidth between file server and the playback laptop.

 

@Miska: Is there any way to try to add caching or additional buffering to HQPlayer/NAA beyond the maximum 250ms setting? I'd be willing to wait for a few seconds for the playback to start, if it takes that long to fill up the cache...

[pkane2001]

44 minutes ago, tboooe said:

@pkane2001 you mentioned that the CPU is at around 50% or less?  ...  Have you tried enabling Multicore DSP in settings?

 

@tboooe, thank you for your response! I do have Multicore DSP enabled. When I mentioned 50% or less, it was usually quite a bit less. 50% being the peak CPU utilization. My laptop has a 2.6ghz, quad-core I7 processor with hyperthreading.

 

All 4 physical cores don't appear to be overloaded, which is what I was trying to convey. There appears to be enough CPU power to do the work.  I am also running a couple more things over what you are describing: I'm running NAA on the same laptop, and I am converting to DoP since that's the only way my DAC understands DSD. So I would expect the CPU utilization to be a bit higher in my case.

[pkane2001]

3 minutes ago, tboooe said:

Did you set the option to the checkmark or the filled in box?  I ask because when I set Multicore DSP to the filled in box (auto mode) I would get some static when converting DSD128 to DSD256.  When I set it to the check mark (force on all the time), the static went away.

Interesting... I didn't see any option other than placing a checkmark next to this setting. I'll have to look again. Maybe it works differently on a Mac vs. PC?

[pkane2001]

1 hour ago, pkane2001 said:

Interesting... I didn't see any option other than placing a checkmark next to this setting. I'll have to look again. Maybe it works differently on a Mac vs. PC?

You're right! I can see that one can either place a check mark or just a gray box in the Multicore DSP selection. I had a checkmark in there already, but now I'm curious as to what the difference might be between the two?

[pkane2001]

17 minutes ago, bogi said:

The difference is described in some extent in HQPlayer manual.

 

Thanks, just found it. I don't normally re-read the manual with each new software release, and this option was not there in HQP v3.1 that I was using until recently. That's my story and I'm sticking to it! 

[pkane2001]

17 minutes ago, tboooe said:

So, did changing the Muticore DSP setting help at all?

 

Not really, since I already had that setting checked. But, I did find something that appears to help. 

 

What I did was to move the WiFi repeater into a closet, up high, near the basement ceiling (closer to the WiFi base), and away from all the audio equipment. According to DD-WRT signal quality improved from about 58% to 70%. So far, no drop-outs even while playing 192/24 files over WiFi. I'm cautiously optimistic  but need more listening time to be sure.

[pkane2001]

On 3/31/2017 at 3:53 PM, pkane2001 said:

What I did was to move the WiFi repeater into a closet, up high, near the basement ceiling (closer to the WiFi base), and away from all the audio equipment. According to DD-WRT signal quality improved from about 58% to 70%. So far, no drop-outs even while playing 192/24 files over WiFi. I'm cautiously optimistic  but need more listening time to be sure.

 

Just to close the loop: no drop-outs at all after the above adjustment. Thank you to all who offered advice and explanation!

 

Still playing through NAA running on the same Macbook Pro that's running HQPlayer.

 

Here's the system playing 192/24 FLAC file (Miles Davis, Kind of Blue) converted to DSD256. Interesting that sometimes the transfer changes to larger chunks resulting in no need to fetch anything else over WiFi for a bit, and then suddenly jumping back up to maximum. This causes the large swings in bandwidth usage. It doesn't seem to cause any problems with the playback, and I suspect it has to do more with how the file is compressed, than with any issues with WiFi or with buffering.

[pkane2001]

@Miska: is there a way to specify a network card to use with HQPlayer for multicast to NAA? I have a Windows 10 PC with two network cards. One is wirelessly connected to my NAS drive, the other I'd like to connect directly to the NAA using ethernet. I need a way to tell HQPlayer which network card to use to find the NAA. Any suggestions?

[pkane2001]

3 hours ago, Miska said:

That is wrong question to ask, right question would be how to arrange your OS routing table so that multicasts are routed the way you want...

 

That's the question I wanted to ask!  I didn't think that was possible, but will take a second look.

 

I guess the answer to my first question is 'no'?

 

[pkane2001]

3 hours ago, pkane2001 said:

That's the question I wanted to ask!  I didn't think that was possible, but will take a second look.

 

Solved by setting the priority metric on the NAA network interface higher than on the NAS interface. HQPlayer connects to NAA and sees NAS through two different interfaces. Thanks for pointing me in the right direction, @Miska!