HQPlayer Linux Desktop and HQplayer embedded

[randytsuch]

1 hour ago, craighartley said:

Can anyone help or advise me? I've been trying to make a bootable USB stick with the latest version of hqplayer-embedded-4.13.0-x64. I've had not trouble in the past doing this with Balena Etcher on my Mac, but every time I download it I'm getting 'wrong checksum' messages when I try to extract the zip file downloaded from the Signalyst site. I can find a couple of extractors (including unRAR) that will extract the zip file, but then when I try to flash it to the USB stick, I get an error message telling me to check whether the file is corrupted. Any ideas?

 

thanks

Craig

I made a stick of this last night on my mac.  Runs fine, listened to new version.

 

Used https://theunarchiver.com/ to unzip then Balena Etcher to make the stick and it was fine for me.

 

EDIT:  I'm uploading it to my google drive, but will take a while to upload, hour or so.

 

Randy

[craighartley]

48 minutes ago, randytsuch said:

I made a stick of this last night on my mac.  Runs fine, listened to new version.

 

Used https://theunarchiver.com/ to unzip then Balena Etcher to make the stick and it was fine for me.

 

EDIT:  I'm uploading it to my google drive, but will take a while to upload, hour or so.

 

Randy

Thanks. I’ve just got it to work after updating to the latest version of Etcher. 

[craighartley]

Miska,

 

Now I've updated to the latest version of the embedded bootable image, it won't connect with my NAA. Please see following log: the bootable image is at the address 192.168.1.128; the NAA is named 'OrfeoRendu' and is on 192.168.1.132.

 

  2019/12/21 16:40:31 asoundlib version: 1.1.9
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=3 - HDA NVidia: HDMI 0
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=7 - HDA NVidia: HDMI 1
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=8 - HDA NVidia: HDMI 2
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=9 - HDA NVidia: HDMI 3
  2019/12/21 16:40:31 Network Audio IPv6 support enabled
  2019/12/21 16:40:31 Discovery from 0.0.0.0
& 2019/12/21 16:40:31 Discovered network audio: name='hqplayer' version='Signalyst Network Audio Daemon 3.6.0'  @192.168.1.132:43210
& 2019/12/21 16:40:31 Discovered network audio: name='hqplayer' version='Signalyst Network Audio Daemon 3.6.0'  @192.168.1.132:43210
& 2019/12/21 16:40:31 Discovered network audio: name='OrfeoRendu' version='Signalyst Network Audio Daemon 3.5.6'  @192.168.1.128:43210
& 2019/12/21 16:40:31 Discovered network audio: name='OrfeoRendu' version='Signalyst Network Audio Daemon 3.5.6'  @192.168.1.128:43210
  2019/12/21 16:40:32 Discovery from ::
# 2019/12/21 16:40:32 clNetMiniEngine::DeviceLookup(): clNetMiniEngine::Disco(): clSocket::SendTo(): sendto(): Cannot assign requested address
- 2019/12/21 16:40:32 Network engine stopping...

 

thanks

Craig

[Outlaw]

7 hours ago, craighartley said:

Miska,

 

Now I've updated to the latest version of the embedded bootable image, it won't connect with my NAA. Please see following log: the bootable image is at the address 192.168.1.128; the NAA is named 'OrfeoRendu' and is on 192.168.1.132.

 

  2019/12/21 16:40:31 asoundlib version: 1.1.9
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=3 - HDA NVidia: HDMI 0
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=7 - HDA NVidia: HDMI 1
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=8 - HDA NVidia: HDMI 2
  2019/12/21 16:40:31 Found ALSA device: hw:CARD=NVidia,DEV=9 - HDA NVidia: HDMI 3
  2019/12/21 16:40:31 Network Audio IPv6 support enabled
  2019/12/21 16:40:31 Discovery from 0.0.0.0
& 2019/12/21 16:40:31 Discovered network audio: name='hqplayer' version='Signalyst Network Audio Daemon 3.6.0'  @192.168.1.132:43210
& 2019/12/21 16:40:31 Discovered network audio: name='hqplayer' version='Signalyst Network Audio Daemon 3.6.0'  @192.168.1.132:43210
& 2019/12/21 16:40:31 Discovered network audio: name='OrfeoRendu' version='Signalyst Network Audio Daemon 3.5.6'  @192.168.1.128:43210
& 2019/12/21 16:40:31 Discovered network audio: name='OrfeoRendu' version='Signalyst Network Audio Daemon 3.5.6'  @192.168.1.128:43210
  2019/12/21 16:40:32 Discovery from ::
# 2019/12/21 16:40:32 clNetMiniEngine::DeviceLookup(): clNetMiniEngine::Disco(): clSocket::SendTo(): sendto(): Cannot assign requested address
- 2019/12/21 16:40:32 Network engine stopping...

 

thanks

Craig

I could not connect  when i tried connecting with IPv6 enabled.I unchecked box and connected for me

[Le Concombre Masqué]

1 hour ago, Outlaw said:

I could not connect  when i tried connecting with IPv6 enabled.I unchecked box and connected for me

The one thing I did not think of trying 

thank you 

@Miska had the exact same log error as Craig : not a Mac HW issue....

[Le Concombre Masqué]

Works great

 

now it would be great to have convolution SAVE option under Matrix as well

 

 

[craighartley]

9 hours ago, Outlaw said:

I could not connect  when i tried connecting with IPv6 enabled.I unchecked box and connected for me

Thanks! Yes that works for me too. It seems having the IPv6 box checked stops it working in the new version. It was fine with the previous. 

[bodiebill]

1 hour ago, asdf1000 said:

Hi @Miska

My i9-9900K has been running both EC modulators fine until HQP Embedded v4.13 

Now have stuttering with 4.13

Is there a known issue with v4.13?

 

Similar to my problem. I changed to 4.13 about the same time I changed to Apacer RAM. Doubling RAM to 16GB did not help: I still have occasional dropouts, even if I only upsample to DSD128, so maybe it is indeed the HQP version?

[asdf1000]

1 hour ago, bodiebill said:

 

Similar to my problem. I changed to 4.13 about the same time I changed to Apacer RAM. Doubling RAM to 16GB did not help: I still have occasional dropouts, even if I only upsample to DSD128, so maybe it is indeed the HQP version?

 

Still error on my part. I forgot EC modulators won't work at DSD512.

 

Everything is working ok with v4.13 with my i9-9900K, as before.

 

 

 

 

 

[craighartley]

On 12/22/2019 at 9:13 AM, craighartley said:

Thanks! Yes that works for me too. It seems having the IPv6 box checked stops it working in the new version. It was fine with the previous. 

Like others, I'm having occasional dropouts with 4.13 Embedded, which I suppose is likely to be related to the fact that it won't work with the IPv6 box checked. I never had dropouts with the previous version. 

[Miska]

2 hours ago, craighartley said:

Like others, I'm having occasional dropouts with 4.13 Embedded, which I suppose is likely to be related to the fact that it won't work with the IPv6 box checked. I never had dropouts with the previous version. 

 

There are no networking related changes at all, between 4.12 and 4.13. HQPlayer OS got updated in between, but HQPlayer itself didn't get any networking changes.

 

On 12/21/2019 at 7:43 PM, craighartley said:

Now I've updated to the latest version of the embedded bootable image, it won't connect with my NAA. Please see following log: the bootable image is at the address 192.168.1.128; the NAA is named 'OrfeoRendu' and is on 192.168.1.132.

 

In this case, there are only IPv4 addresses around, so you can as well disable IPv6 support. I'll check if I can reproduce this problem with IPv6 support enabled. But a bit strange that even for the local NAA there's no IPv6 response.

 

[Miska]

On 12/21/2019 at 4:14 PM, craighartley said:

Can anyone help or advise me? I've been trying to make a bootable USB stick with the latest version of hqplayer-embedded-4.13.0-x64. I've had not trouble in the past doing this with Balena Etcher on my Mac, but every time I download it I'm getting 'wrong checksum' messages when I try to extract the zip file downloaded from the Signalyst site. I can find a couple of extractors (including unRAR) that will extract the zip file, but then when I try to flash it to the USB stick, I get an error message telling me to check whether the file is corrupted. Any ideas?

 

Here's the official site for the compression tool used to compress the images:

https://www.7-zip.org

 

Reason for using this compressor is that it manages to compress things almost twice as much compared to old ZIP...

[craighartley]

41 minutes ago, Miska said:

 

There are no networking related changes at all, between 4.12 and 4.13. HQPlayer OS got updated in between, but HQPlayer itself didn't get any networking changes.

 

 

In this case, there are only IPv4 addresses around, so you can as well disable IPv6 support. I'll check if I can reproduce this problem with IPv6 support enabled. But a bit strange that even for the local NAA there's no IPv6 response.

 

Thanks. The only change I’ve made is updating bootable image, and now I have no IPv6 support possible and occasional dropouts. This is annoying enough to make me go back to the previous version of the bootable image, which worked perfectly for me, but I’ll hold out to see if you can reproduce it. 

[Miska]

1 minute ago, craighartley said:

Thanks. The only change I’ve made is updating bootable image, and now I have no IPv6 support possible and occasional dropouts. This is annoying enough to make me go back to the previous version of the bootable image, which worked perfectly for me, but I’ll hold out to see if you can reproduce it. 

 

Is the old one using IPv6 or just IPv4 compatibility fallback?

 

Any dropouts are more likely to do with filter setting combined with the particular CPU model. What are the filter + modulator settings on which CPU model?

 

There are two aspects in play here;

1) Updated HQPlayer OS that may have impact on IPv4/IPv6 behavior (no related changes at HQPlayer side, just the OS)

2) Updated core allocation code in HQPlayer having impact on performance with given CPU model + filter + modulator combination

 

[craighartley]

14 minutes ago, Miska said:

 

Is the old one using IPv6 or just IPv4 compatibility fallback?

 

Any dropouts are more likely to do with filter setting combined with the particular CPU model. What are the filter + modulator settings on which CPU model?

Not sure I understand the first question. NAA is MicroRendu using your Cubox/Rendu NAA image. 
 

Server with HQPOS has 6700K overclocked to 4.7 GHz, using Poly Sinc long lp filter (for Hires files) and long lo-2s (for 1x files), and 7th order EC modulator.

 

Quote

There are two aspects in play here;

1) Updated HQPlayer OS that may have impact on IPv4/IPv6 behavior (no related changes at HQPlayer side, just the OS)

2) Updated core allocation code in HQPlayer having impact on performance with given CPU model + filter + modulator combination

 

I’ll try some other filters to see if dropouts disappear, but I had no dropouts with this combination previously. 

[Miska]

10 minutes ago, craighartley said:

Not sure I understand the first question. NAA is MicroRendu using your Cubox/Rendu NAA image. 

 

IPv6 has backwards compatibility mode where entire IPv4 address space is mapped into small subnet of IPv6 address space. The question is if the address used is IPv4 mapped into IPv6 space or a real IPv6 address. This is visible from the log files.

 

14 minutes ago, craighartley said:

Server with HQPOS has 6700K overclocked to 4.7 GHz, using Poly Sinc long lp filter (for Hires files) and long lo-2s (for 1x files), and 7th order EC modulator.

 

Quote

There are two aspects in play here;

1) Updated HQPlayer OS that may have impact on IPv4/IPv6 behavior (no related changes at HQPlayer side, just the OS)

2) Updated core allocation code in HQPlayer having impact on performance with given CPU model + filter + modulator combination

 

Read more  

I’ll try some other filters to see if dropouts disappear, but I had no dropouts with this combination previously. 

 

OK, that is strange because the core allocation changes are not affecting this CPU. Only ones that have >= 8 cores (6700K is quad core). So I don't have any straightforward answer to this one...

 

[craighartley]

18 minutes ago, Miska said:

 

IPv6 has backwards compatibility mode where entire IPv4 address space is mapped into small subnet of IPv6 address space. The question is if the address used is IPv4 mapped into IPv6 space or a real IPv6 address. This is visible from the log files.

 

 

OK, that is strange because the core allocation changes are not affecting this CPU. Only ones that have >= 8 cores (6700K is quad core). So I don't have any straightforward answer to this one...

 

Ok thanks. So I should look at logusing previous version of HQPOS?  (I’ll need to reflash this)

[craighartley]

36 minutes ago, Miska said:

 

IPv6 has backwards compatibility mode where entire IPv4 address space is mapped into small subnet of IPv6 address space. The question is if the address used is IPv4 mapped into IPv6 space or a real IPv6 address. This is visible from the log files.

 

 

OK, that is strange because the core allocation changes are not affecting this CPU. Only ones that have >= 8 cores (6700K is quad core). So I don't have any straightforward answer to this one...

 

Miska, I’ve just noticed that my router shows the HQPOS machine appearing connected twice with two different addresses. How can this happen?!

[Miska]

13 hours ago, craighartley said:

Miska, I’ve just noticed that my router shows the HQPOS machine appearing connected twice with two different addresses. How can this happen?!

 

The other one is likely an old not yet expired lease while the other one is current. This can happen if you reboot without proper shutdown, since in such case the lease is not released. Some DHCP servers then issue a new lease after reboot even though the MAC address would be the same (unless static address is defined for the MAC).

 

13 hours ago, craighartley said:

Ok thanks. So I should look at logusing previous version of HQPOS?  

 

You can do that if it works better. Would be good to check load distributions with "htop" first on the newer image and then on the older one, when using exactly same settings (you can easily do that by using settings backup/restore functionality).

 

[Rune]

20 hours ago, Miska said:

The other one is likely an old not yet expired lease while the other one is current. This can happen if you reboot without proper shutdown, since in such case the lease is not released. Some DHCP servers then issue a new lease after reboot even though the MAC address would be the same (unless static address is defined for the MAC).

I also got double entries in my router because HQPlayer got a new MAC address when updating to newest version. And therefore had to update the IP address reservation in my router.

[Miska]

47 minutes ago, Rune said:

I also got double entries in my router because HQPlayer got a new MAC address when updating to newest version. And therefore had to update the IP address reservation in my router.

 

Since HQPlayer OS runs interfaces bridged, the bridge interface gets a virtual MAC by default. You can specify a static MAC (for example copy MAC of one of the physical interfaces) to the bridge device by editing /etc/systemd/network/10-br0.netdev and specifying MAC address using "MACAddress=" under [NetDev] section.

 

[craighartley]

1 hour ago, Miska said:

 

Since HQPlayer OS runs interfaces bridged, the bridge interface gets a virtual MAC by default. You can specify a static MAC (for example copy MAC of one of the physical interfaces) to the bridge device by editing /etc/systemd/network/10-br0.netdev and specifying MAC address using "MACAddress=" under [NetDev] section.

 

I’m getting confused with this: which device do you mean by the ‘bridge device’ in this instance: the naa?

[Miska]

27 minutes ago, craighartley said:

I’m getting confused with this: which device do you mean by the ‘bridge device’ in this instance: the naa?

 

Since some boards like the UpSquared has two ethernet interfaces, HQPlayer OS bundles these into one virtual interface (bridge). So each port is member of a software switch and thus you can use any of the ports for connecting to a network. This also means HQPlayer OS has a single IP address regardless of number of ports. This happens also in case you have only a single interface.

 

This is because the image cannot know about the particular hardware configuration, but still is supposed to be "plug and play".

 

NAA image doesn't do this and thus can only operate on a network where every port is connected to a network with DHCP service. (practically only on hardware that has only single port)

 

[craighartley]

Am I right in thinking that if I’m using the bootable HQP image, the system doesn’t actually need a hard disk to function as a HQPlayer server?
 

(reposted as I accidentally put in the wrong thread)

[randytsuch]

2 hours ago, craighartley said:

Am I right in thinking that if I’m using the bootable HQP image, the system doesn’t actually need a hard disk to function as a HQPlayer server?
 

(reposted as I accidentally put in the wrong thread)

I boot directly from USB with HQP OS, so I can't imagine a ssd/hdd is required.

Didn't actually remove my ssd, although I should so it will only boot from usb.