HQPlayer Linux Desktop and HQplayer embedded

[luisma]

wrong topic posting just edited

[luisma]

1 minute ago, Johnseye said:

@Miska , I am running Audiolinux (Arch Linux) with your HQPlayer 3.23 Desktop package.  ALSA driver with a Holo Spring L3 DAC.  The DAC can accept PCM 384 and DSD 512.  I was previously running HQPlayer on Windows Server 2016 and was able to upsample to both those frequencies.  With the Linux flavor at 3.23 I need to have autorate enabled or else I get static with PCM and a slower speed playback with DSD.  

I know the question is @Miska but I might have had a similar issue, when you say "static" is it like white noise type of sound?

if it is I found on my connection to my DAC it helped having these installed

libasound2 libasound2-data libasound2-plugins

 

Don't know how is it related but it helped my DAC communication issues

 

And most definitely having an NAA in the middle helped as well

 

In my specific case, it may not apply to you

 

[luisma]

No problem. That happened to me and the only way to get out of it was switching HQP from PCM to SDM or viceversa or change the sampling, dithering parameters, that fixed the issue.

Then I added an NAA (installing those packages) and the issue was COMPLETELY gone and I blamed the direct connection.

But then I switched back to direct USB connection after installing the packages I just mentioned and the issue did not happened again.

So for sure the NAA removed the issue and very likely the packages were the reason

 

You try for yourself and maybe Miska will provide some more insight into this

 

[luisma]

JM:

 

Interesting and detailed post, I went through all that recently and have my own guide which I will be reviewing.

 

For fast testing be sure to enable and select IPv6 on the HQPE config page, that was something preventing me from seeing the NAA

 

More details to come

 

[luisma]

it is not listed but you have knowledge of Linux just to be sure you have this enabled?

systemctl enable networkaudiod.service

systemctl start networkaudiod.service

 

I do have the same config as you with the only addition of Roon Bridge on the NAA

 

My HQPE and ROON Core server has ethernet directly connected to my NAA + Roon Bridge endpoint. Each the server and the NAA has wireless for management and Tidal streaming. With Ruckus Wireless R710 and 5.2 GHZ I have sustained 32 mbits / second wireless performance. 

 

 

[luisma]

Funny enough I just today, this morning, started testing a pre amp with no remote control as I just replaced my integrated A-S2100. The volume control is a very nice touch and convenient.

 

But

 

Haven't we discussed already that digital volume modification affects the original SQ? or is it was another thread?

 

[luisma]

Thanks for providing this insight Jussi, if I remember correctly this was discussed with the volume settings on Roon not specifically HQP, I would have imagined that analog resistor based volume controls were preferred to digital ones but I guess since HQP modifies the audio regardless and since the creator of HQP can embed in the code the volume / gain manipulation at the exact right step within the conversion process this will work better anyways.... good to know we can take advantage of this feature

 

Thank you again

 

 

[luisma]

19 hours ago, Miska said:

When HQPlayer has volume control enabled, Roon is able to handle this control. So if you adjust volume from Roon in this case, it is passed on to HQPlayer. This can be fairly convenient.

That is great, so Roon won't do its own modifications but actually queue the volume control settings to HQPE, I was trying to play around with the HQPE homepage volume but this seems to be meant more an info lever than an actual volume change

will try it from Roon then 

[luisma]

So these are my HQPE settings

then Roon Settings

 

[luisma]

This is so convenient I just upgraded to a pre amp which is very good but without a remote and this just makes my day ... 

[luisma]

22 hours ago, Miska said:

But overall, this discussion shows exactly why I want to keep doing my HQPlayer OS images. I don't mind other people doing different way either. I just personally feel that I know what I'm doing after having been working on embedded systems for a long time.

We know you know what you are doing

My HQPE runs with SSD and RAM and my NAA runs on SSD and RAM too and no fan.

If I am using your kernel on my own install vs your complete image? the power states, ACPI and everything else is the same "as your bootable image" correct? I know packages may differ and so on but the power states etc will remain the same?

 

[luisma]

56 minutes ago, acatala said:

Linux and macOS boxes use DoP when streaming DSD to a DAC.

I don't know about Macs but Linux have ALSA generic drivers and I was under the impression if the DAC supports PCM and DSD it will stream DSD directly to the DAC not DoP

If I am mistaken let me know 

 

[luisma]

Hi Jussi, this may look off topic first but it is related. Following other threads here in CA (should I say AS?) people are using ramroot Audio  Linux installs on their NUCs and NAAs, I am very happy currently using my own Ubuntu install with your custom kernel on both NUC with HQPE and NUC with NAA. Is it worth to move the HQPE and NAA over to AL? has you or anyone done the comparison?

 

[luisma]

I guess AL vs Ubuntu custom kernel there should not be much difference

 

So you run HQPE on Ubuntu Server, Debian 9 Stretch and Fedora 29 or the NAA runs on the latter?

[luisma]

Thanks, I have the power NUC with core i7 running HQPE on Ubuntu my own install but with your kernel

The NAA is Ubuntu on a core i3 fanless with your kernel as well

 

Not using your bootable image because the NAA has also Roon Bridge for testing roon to roon playing 

 

So far very satisfied but noticed the Audiolinux references on another thread 

 

 

 

[luisma]

22 hours ago, Bob Stern said:

What are the Ubuntu shell commands to download and install HQP Embedded and its dependencies?  (Assuming I don’t have the luxury of Mac shared folders

You running bionic beaver or 16.04? I believe for the new HQPE you must have bionic beaver. 

[luisma]

After upgrading to https://www.signalyst.eu/bins/hqplayerd/bionic/hqplayerd_4.10.2-29_amd64.deb

and https://www.signalyst.eu/bins/naa/images/naa-3561-x64.7z

I have been unable to connect from my HQPE PC running Ubuntu to the NAA

 

I was connecting fine before and also I was connecting to audiolinux networkaudiod, tried audiolinux and could not connect either.

 

Downgraded the NAA image back to 356 (The Feb 2019 release) and can't connect either.

 

Network settings are the same, DAC is the same, cables are the same. I am wondering if it is an HQPlayer issue?

 

This is the output of /tmp/hqplayerd.log

root@nucplayer:~# tail -f /tmp/hqplayerd.log 
  2019/06/06 17:25:03 Discovery from 0.0.0.0
  2019/06/06 17:25:04 Discovery from ::
  2019/06/06 17:25:05 Discovered 0 Network Audio Adapters
  2019/06/06 17:25:05 Network Audio IPv6 support enabled
  2019/06/06 17:25:05 Discovery from 0.0.0.0
  2019/06/06 17:25:06 Discovery from ::
  2019/06/06 17:25:07 Discovered 0 Network Audio Adapters
  2019/06/06 17:25:07 Network Audio IPv6 support enabled
  2019/06/06 17:25:07 Discovery from 0.0.0.0
  2019/06/06 17:25:08 Discovery from ::
  2019/06/06 17:25:09 Discovered 0 Network Audio Adapters
  2019/06/06 17:25:09 Network Audio IPv6 support enabled
  2019/06/06 17:25:09 Discovery from 0.0.0.0

 

The NAA is visible

root@nucplayer:~# ping 192.168.96.229
PING 192.168.96.229 (192.168.96.229) 56(84) bytes of data.
64 bytes from 192.168.96.229: icmp_seq=1 ttl=64 time=0.819 ms
64 bytes from 192.168.96.229: icmp_seq=2 ttl=64 time=0.882 ms

 

This is the network config on the NAA

 

networkaudiod is running

 

I tried many things except going back to a former version of HQPE could this be issue?

 

If I connect the DAC via ALSA directly to the HQPE PC it works flawless

 

 

 

 

[luisma]

downgraded HQP to 4.9.1-26 now no getting in the log the infinite loop just this

 2019/06/06 17:48:28 libDSP version 20.7.1
  2019/06/06 17:48:28 HQPlayer Engine version 4.13.1
  2019/06/06 17:48:28 Number of processor cores: 2
  2019/06/06 17:48:28 DSP thread pools disabled
  2019/06/06 17:48:28 Pipelined DSP disabled
  2019/06/06 17:48:28 Audio engine: network
  2019/06/06 17:48:28 Network Audio IPv6 support disabled
  2019/06/06 17:48:28 Discovery from 0.0.0.0
  2019/06/06 17:48:29 Discovered 0 Network Audio Adapters
  2019/06/06 17:48:29 Output set channels: 2 (2)
! 2019/06/06 17:48:29 clPlayerDaemon::CreateEngine(): clHQPlayerEngine::Initialize(): clNetMiniEngine::Initialize(): adapter not found
- 2019/06/06 17:48:29 Network engine stopping...
% 2019/06/06 17:48:29 ...configuration reloaded
  2019/06/06 17:48:36 asoundlib version: 1.1.3
  2019/06/06 17:48:36 Network Audio IPv6 support enabled
  2019/06/06 17:48:36 Discovery from ::
- 2019/06/06 17:48:38 Network engine stopping...

 

Still can't find the NAA

 

Enabling Roon Bridge on Audiiolinux the Roon server on the PC can find the other PC just fine.

 

@Miska, anything I may be missing and why the NAA is not seen anymore?

 

 

[luisma]

This is the output of HQP when starting the service

* 2019/06/07 11:33:35 Signalyst HQPlayer 4 Embedded 4.9.1
+ 2019/06/07 11:33:35 Engine starting...
  2019/06/07 11:33:35 libDSP version 20.7.1
  2019/06/07 11:33:35 HQPlayer Engine version 4.13.1
  2019/06/07 11:33:35 Number of processor cores: 2
  2019/06/07 11:33:35 DSP thread pools disabled
  2019/06/07 11:33:35 Pipelined DSP disabled
  2019/06/07 11:33:35 Audio engine: network
  2019/06/07 11:33:35 Network Audio IPv6 support enabled
  2019/06/07 11:33:35 Discovery from ::
  2019/06/07 11:33:37 Discovered 0 Network Audio Adapters
  2019/06/07 11:33:37 Output set channels: 2 (2)
! 2019/06/07 11:33:37 clPlayerDaemon::CreateEngine(): clHQPlayerEngine::Initialize(): clNetMiniEngine::Initialize(): adapter not found
- 2019/06/07 11:33:37 Network engine stopping...
+ 2019/06/07 11:33:37 Server starting...

 

 

This is the output of the networkaudiod at the same time

[root@audiolinux /]# networkaudiod
[networkaudiod] (2468): networkaudiod Copyright (C) 2011-2019 Jussi Laako / Signalyst. All rights reserved.
[networkaudiod] (2468): asoundlib version: 1.1.9
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
[networkaudiod] (2468): clSocket::SetOption(): setsockopt(): No such device
^C[networkaudiod] (2468): ALSA backend uninitialized

[luisma]

Yeah I agree it is a network issue on the HQPE side, default route points to the other adapter remember is multi homed so the default route won't go towards the NAA network but it should not matter 

Weird thing euphony NAA gets discovered, your NAA image and Audiolinux NAA won't, I can send you logs 

[luisma]

18 hours ago, Miska said:

 

No, it's network problem at the NAA side, because the networkaudiod is not coming up properly, but instead running in a loop trying to get started.

 

If you use multi-homed setup, you need to then explicitly route multicasts towards the interface where NAA is. Otherwise it takes default route and of course doesn't end up at the NAA.

 

I personally don't understand why someone would like to use multi homed setup...

 

My internet comes in at the second floor, my music system is in the 1st floor. I love cables but renting this place I cannot have someone to come in and run a cable downstairs because of the landlord won't allow it and on top of that buildings were I live (Florida) usually they don't have good conduits like they do in Europe so my solution was wireless. So I have a wireless NUC using wifi for streaming (and access) and wired ethernet to the NUC NAA, I am forced to use dual adapters because of the situation not by choice. I already made a long cable from the upstair bedroom to the living room all over the stairs and through the living room and my wife said enough is enough so yeah, not a real option.

 

I will be looking into the multicast routes, I had a similar issue before and you advised IP4 IPs were required on the NAA side and that fixed the issue and it was working fine multihomed uintil a week ago with that same Ubuntu and your NAA image, I started testing Euphony and when I went back to your NAA image it did not worked, I tried also Audiolinux which was working before and did not work either. If it would be an issue on the NAA side why was working fine before multihomed with your NAA and AL and why it is working now but only with Euphony NAA? 

 

I tried to avoid asking you as I know you are very active with other things in these forums and really something simple I rather find myself the answer but in this specific case since there was updates involved etc. I asked, but like you said and since no one else reported this it is a network issue so I will figure it out.

 

And I'm quite puzzled as of why does it work with the Euphony NAA so I need to find out.

 

Thanks for the tip on the multicast

 

Best Wishes

 

Luis

 

[luisma]

2 hours ago, Miska said:

Are you using my latest 3.5.6.1 image and hqplayerd 4.10.2?

Yes

2 hours ago, Miska said:

Both HQPlayer and NAA by default use both IPv4 and IPv6 in parallel. HQPlayer picks up IPv6 if NAA is found through IPv6, if not it falls back to IPv4.

Both NAA and HQPE have IPv4 and IPv6 addresses and can ping each other on either one

 

2 hours ago, Miska said:

This indicates that it is somehow NAA side issue...

Well Logic indicates such but the ones that won't work are your "unspoiled" NAA image which I cannot change anyways as it boots from the USB and the AL networkaudiod which was just working fine before.

 

tcpdump doesn't show multicast traffic out of the wired interface when starting HQPE however there are multicast routes etc. so I am at that point now, I will keep you posted on whatever I do.

 

2 hours ago, Miska said:

One solution to simplify the setup and make it more flexible is to use a wireless bridge between the floors. No need for tricky multi-homed setups and much more flexible network.

The thing is I am using Ruckus wireless access points with a network controller as well, these are very very good but the only way to bridge would be with adding a second AP downstairs and use mesh but I think I can get better speed and simplicity and cost using just one AP. Thanks for the tip. It has to work multi homed I just haven't been able to figure it out but I will ... 

 

thanks for answering I will keep you posted.

 

[luisma]

3 hours ago, Miska said:

 

You can explicitly define which interface to use for multicast by manually editing the hqplayerd.xml configuration file. In the <network> element you can specify attribute "mcast_interface" and the value is name of the interface to use (same names "ifconfig" shows). There's also magic value "*" that just picks up the first one. If a value is defined, the available interfaces are also listed in the log file. List is filtered to cover only interfaces that are capable of both IPv4 and IPv6 multicast!

 

Note that this feature has not been tested very much!

That's extremely valuable, let me give that a try

thank you

 

[luisma]

6 hours ago, Miska said:

For example this device seems to have Client Mode where it connects to existing AP and bridges it to the four gigabit ethernet ports:

https://www.zyxel.com/products_services/AC2100-Dual-Band-Wireless-Gigabit-Access-Point-Range-Extender-ARMOR-X1/

There are many other similar ones too.

Thanks

 

[luisma]

Posted this on HQPlayer by mistake, it belongs here.

Listening to the new modulators now, can only do DSD128 with 7EC but I am pleasantly surprised, more by the fact that Jussi knowing how improved the modulators are haven't praised these too much publicly leaving the feedback to the community. 

I was exclusively doing straight PCM, not because HQPlayer is bad but because with my specific system (dac speakers etc) PCM is very detailed which I like, now I hate to have to accept this but software algorhtym alone may have improved over the dacs transistor ladder. I'm testing poli mqa mp 1x and nx, I can only imagine how other filters and DSD512 may sound. The modulator clarity and separation and noise it's amazing 

 

Last but certainly not least the algorhtym is someone's creation after much experience in this field, very well done sir, IMO this makes more of difference than filters when fed with high quality source content.