HQPlayer's Network Audio Adapter

[gixxer]

Hello,

 

Having issue discovering NAA device on Windows 10 Pro.  Log file snippet below.  

 

This symptom can be recreated with both version 3 and 4 of HQPlayer Desktop from the same Windows 10 Pro machine.

 

The relevant part is discovering 0 NAA.

* 2019/10/14 09:14:36 Starting...
  2019/10/14 09:14:36 Signalyst HQPlayer Desktop v3.25.4
  2019/10/14 09:14:36 Engine selected: 
  2019/10/14 09:14:41 Restore GUI state
  2019/10/14 09:14:41 libDSP version 20.7.3
  2019/10/14 09:14:41 CUDA convolution offload requested
  2019/10/14 09:14:41 Number of processor cores: 6
  2019/10/14 09:14:41 DSP thread pools enabled (2)
  2019/10/14 09:14:41 Pipelined DSP enabled
  2019/10/14 09:14:41 Audio engine: network
  2019/10/14 09:14:41 Network Audio IPv6 support disabled
  2019/10/14 09:14:41 Discovery from 0.0.0.0
  2019/10/14 09:14:42 Discovered 0 Network Audio Adapters
  2019/10/14 09:14:42 Set channels: 2 (2)
! 2019/10/14 09:14:42 createEngine(): clHQPlayerEngine::Initialize(): clNetMiniEngine::Initialize(): adapter not found

 

I have disabled all firewall settings from Windows Security, domain/private/public network firewall are all off.

 

I have recreated with different Windows 10 Pro machine in the same network, much more bear-bone configuration. 

 

Is there something i'm missing from my setup with HQP versions 3 and 4 with regards to using them in Windows 10 system?

 

Basic communication tests between Windows 10 Pro network interface and microrendu IP address, show reachable.  And firewall has been disabled at Windows 10 Pro side.

 

C:\Users\georg>tracert 192.168.90.128

Tracing route to RENDU-010268 [192.168.90.128]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  RENDU-010268 [192.168.90.128]

Trace complete.

C:\Users\georg>

    C:\Users\georg>ping 192.168.90.128

Pinging 192.168.90.128 with 32 bytes of data:
Reply from 192.168.90.128: bytes=32 time<1ms TTL=64
Reply from 192.168.90.128: bytes=32 time<1ms TTL=64
Reply from 192.168.90.128: bytes=32 time<1ms TTL=64
Reply from 192.168.90.128: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.90.128:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\georg>

 

 

 

As a comparison, the same NAA device however can be seen from Windows 7 Pro machine.  It's log snippet here.  And there is only one NAA device in the local network.

 

* 2019/10/14 08:58:07 Starting...
  2019/10/14 08:58:07 Signalyst HQPlayer Desktop v3.25.4
  2019/10/14 08:58:07 Engine selected: 
  2019/10/14 08:58:12 Restore GUI state
  2019/10/14 08:58:12 libDSP version 20.7.3
  2019/10/14 08:58:12 CUDA convolution offload requested
  2019/10/14 08:58:12 Number of processor cores: 8
  2019/10/14 08:58:12 DSP thread pools enabled (3)
  2019/10/14 08:58:12 Pipelined DSP enabled
  2019/10/14 08:58:12 Audio engine: network
  2019/10/14 08:58:12 Network Audio IPv6 support disabled
  2019/10/14 08:58:12 Discovery from 0.0.0.0
& 2019/10/14 08:58:12 Discovered network audio: name='rendu-010268' version='Signalyst Network Audio Daemon 3.5.5'  @192.168.90.128:43210
  2019/10/14 08:58:13  Network endpoint: Brooklyn DAC: USB Audio (hw:CARD=DAC,DEV=0)
  2019/10/14 08:58:13 Discovered 1 Network Audio Adapters
  2019/10/14 08:58:13 Set channels: 2 (2)
+ 2019/10/14 08:58:13 Connect to 192.168.90.128:43210
  2019/10/14 08:58:13 Network format: 44100/32/2 [pcm]

 

 

Thanks much.

 

[gixxer]

14 minutes ago, Miska said:

Please check from Windows 10 network adapter settings window that all other network adapters are disabled. Typically this problem appears when there are multiple active network interfaces.

 

Indeed.

 

Been searching through this forum, and found following post,

 

HQPlayer windows NAA

 

, where you had mentioned the same, i.e.

 

Quote

Relevant part is here. No NAA's found on the network. Please check that on both machines you have only one network interface enabled.

 

For me, consistency is discovering the microrendu after disabling the VirtualBox network interface.

 

Understood the workaround.

 

 

 

My "primary" main Windows box runs Windows 7 Pro and HQPlayer, with only a single network interface. 

 

I needed different box to run some test around HQPlayer + NAA = playback stutters/staggers at different spots in the music playback, and has always been this way.  I've been living with it to a a point where today wanted to try to root cause it.  I knew that there are lot of variables so narrowed down eventually to network/communication between PC and microrendu, which is on the same LAN segment/switch.

 

After trial and errors, found following page that discusses the network interface priority,

 

 

Looked at my setting in the same area, and found this, that "wrong" network interface is at the top,

 

 

Moved the correct connection to the top,

 

 

Keeping everything else the same, had the playback ran for >7 hours.  No drop.  Knock on wood.

 

Test format that previously, consistently shown drops, even with poly-sinc-xtr-2s + ASDM7 + Auto + DSD now plays without drop,

 

44.1k / 224 / 2 --> 11.2896M

 

 

Just banging my head that the fix was this simple.