HQPlayer Linux Desktop and HQplayer embedded

[bodiebill]

5 hours ago, rickca said:

Your i7-9700K is base frequency/turbo frequency of 3.6/4.9 GHz.  It can sustain an all-core turbo of 4.6 GHz.  Handbrake is most likely running multiple cores at high turbo frequencies.  Without some kind of constraints, there's no doubt you will exceed what the 200W LPS can deliver.  The 95W TDP is what's required to run 8 cores at the base frequency of 3.6 GHz.  You can easily double that at all-core turbo.

 

Your motherboard probably isn't contributing much to the load since you don't have a video card, so maybe something like 35W.  Even if you power the motherboard with your Seasonic, and just use the HDPLEX gear to power the CPU, I think you may run into the same problem.  

 

5 hours ago, StreamFidelity said:

Be careful! Always save the working setting under profiles! I would still install the latest BIOS. Before that, be sure to back up the settings to USB Stick. In my BIOS, everything was overwritten with update.

 

Thanks, that is useful guidance. I may experiment with the CPU frequency and/or turbo settings, as long as they continue to enable HQPlayer conversion to DSD256 with the EC modulators.

[bodiebill]

deleted

[Miska]

7 hours ago, bodiebill said:

Same here. But I see no need to store everything as wav. From JRiver I convert an album from flac to wav in 10 seconds and it is automatically put on a RAM drive and sent from Audirvana to the server PC with HQPlayer embedded and then to the endpoint PC with NAA.

 

If you want to just decode a FLAC to WAV, it is easiest and fast through the official "flac" command line utility that can encode and decode FLAC and is part of the original FLAC codec delivery. "flac -d something.flac" decodes to "something.wav".

 

Audirvana will still reshuffle WAV to WAV though.

 

[bodiebill]

10 hours ago, Miska said:

 

If you want to just decode a FLAC to WAV, it is easiest and fast through the official "flac" command line utility that can encode and decode FLAC and is part of the original FLAC codec delivery. "flac -d something.flac" decodes to "something.wav".

 

Audirvana will still reshuffle WAV to WAV though.

 

In Windows, with JRiver it is just (using predefined settings for format and target location):

- select tracks

- click 'convert format'

- click convert

- drag resulting wav files from RAM drive to Audirvana

This takes 10 seconds.

 

The same can be done from file explorer with dBPoweramp by right-clicking the selection and converting.

 

In my case the 'something' bits can be very long so that would be a lot of typing.

 

[Miska]

3 hours ago, bodiebill said:

In Windows, with JRiver it is just (using predefined settings for format and target location):

- select tracks

- click 'convert format'

- click convert

- drag resulting wav files from RAM drive to Audirvana

This takes 10 seconds.

 

The same can be done from file explorer with dBPoweramp by right-clicking the selection and converting.

 

In my case the 'something' bits can be very long so that would be a lot of typing.

 

That still sounds complicated to me... And I don't understand why convert the files and deal with RAM drive, but it's just me...

 

At easiest you can do two commands somewhere for an album:

flac -d *.flac
mv *.wav /somewherelse

 

I can also make a shell script (for tcsh) with something like

foreach flacfile (*.flac)
	flac -d "${flacfile}"
	echo "${flacfile}" | mv `cut -f 1 -d . -`.wav $1
end

or

find . -name '*.flac' -exec flac -d "{}" ";" ; mv *.wav $1

 

[bodiebill]

15 hours ago, bodiebill said:

Thanks, that is useful guidance. I may experiment with the CPU frequency and/or turbo settings, as long as they continue to enable HQPlayer conversion to DSD256 with the EC modulators.

 

Switching off turbo boost in the BIOS resulted in small dropouts when converting to DSD256 with the ASDM7EC modulator, so that is no option. I could switch off turbo mode before booting Windows.

[bodiebill]

2 hours ago, Miska said:

And I don't understand why convert the files and deal with RAM drive, but it's just me...

 

Maybe you're right. When playing with a dual PC setup I thought I heard a difference between flac and wav, and also between RAM drive and NAS. However, now with my triple PC setup, I have a hard time to hear the difference. Converting had become like a little ritual. And as it is with rituals: they give peace of mind, even if they offer no other verifiable benefits.

[Spindrift1414]

Really enjoying the new release - just a quick question regarding the new filters and my apologies if this was already answered but I couldn’t find it in the past couple pages. .. 

 

is the poly-sinc-long-ip filter new or is it renamed?  It sounds amazing for classical - open full soundstage with space and detail. But maybe it’s just me . . I’ve been using the minphase filters but this is better for my ears.   The release notes mentioned that the long filter was new but I was just checking to clarify.  
 

Many thanks - cheers!

[cat6man]

On 10/17/2019 at 6:57 PM, Miska said:

 

From Audirvana, or HQPlayer Embedded playing the files?

 

In former case Audirvana decodes FLAC or WAV into WAV stream - in both cases it looks the same to HQPlayer. While if you use some other UPnP Media Server and Control Point to play the same files, they usually end up as-is to HQPlayer.

 

In latter case HQPlayer decodes the actual file. If it makes difference in this case, next question is what kind of media is used to store the files? Advantage of FLAC is that there's about 50% less data to transfer from the storage, while advantage of WAV is that there's less processing to do.

 

 

hqplayer embedded only, never tried audivarna.

music is stored on an external usb3.0 HDD connected directly to NUC running ubuntu.

 

i have no explanation for why wav and flac sound different, but they do (in my system w/ no signal processing).

 

i plan to try upsampling to 192k (max for my dac) in the next few days.

[Miska]

17 hours ago, cat6man said:

hqplayer embedded only, never tried audivarna.

music is stored on an external usb3.0 HDD connected directly to NUC running ubuntu.

 

i have no explanation for why wav and flac sound different, but they do (in my system w/ no signal processing).

 

This is just notably different case compared to streaming from Audirvana, where both cases are sent the same way in WAV format over the network... So from HQPlayer's point of view, and from the HQPlayer computer point of view both cases look the same.

 

My disks are either M.2, SATA or Thunderbolt. On my Linux workstation, disk is connected to SATA. On my Mac disk is connected to Thunderbolt. In all other cases files are accessed over network using SMB protocol (from the SATA disk).

 

[Miska]

18 hours ago, Spindrift1414 said:

is the poly-sinc-long-ip filter new or is it renamed?  It sounds amazing for classical - open full soundstage with space and detail. But maybe it’s just me . . I’ve been using the minphase filters but this is better for my ears.   The release notes mentioned that the long filter was new but I was just checking to clarify.  

 

All poly-sinc-long filters are new. The "ip" version is intermediate phase, meaning a blend between linear and minimum phase.

 

[trs]

HQPlayer embedded has been running well for me, but the other day after updating my kernel it started stopping with a segmentation fault. Systemd keeps restarting the hqplayerd service, but then immediately segfaults. I'm using kernel 5.3.7, with HQPlayer embedded version 4.12.1 and have purchased a license.

 

Is anyone successfully running HQPlayer embedded under kernel 5.3.7, or any other ideas on what might cause the segfault?

[Miska]

4 hours ago, trs said:

HQPlayer embedded has been running well for me, but the other day after updating my kernel it started stopping with a segmentation fault. Systemd keeps restarting the hqplayerd service, but then immediately segfaults. I'm using kernel 5.3.7, with HQPlayer embedded version 4.12.1 and have purchased a license.

 

Is anyone successfully running HQPlayer embedded under kernel 5.3.7, or any other ideas on what might cause the segfault?

 

Which distro are you using?

[trs]

I’m running Clear Linux with a Fedora 30 podman container that runs HQPlayer embedded. Since Fedora 30 looks to be supported I can only guess the Clear Linux kernel may be to blame?

[Miska]

2 hours ago, trs said:

I’m running Clear Linux with a Fedora 30 podman container that runs HQPlayer embedded. Since Fedora 30 looks to be supported I can only guess the Clear Linux kernel may be to blame?

 

Or very likely containers in general...

 

[trs]

So It turns out that Wireguard was the culprit. If the Wireguard network interface is up, HQPe will immediately segfault when starting. @Miska do you have any ideas as how to work around that without disabling Wireguard? Could it be related to ipv6? Thanks!

 

Edit: adding mcast_interface="eno1" to the network tag in hqplayerd.xml seems to have stopped the segault (eno1 is my ethernet interface). Maybe multicast on the Wireguard interface causes an issue? I'm using the network audio adapter for output.

[Miska]

1 minute ago, trs said:

So It turns out that Wireguard was the culprit. If the Wireguard network interface is up, HQPe will immediately segfault when starting. @Miska do you have any ideas as how to work around that without disabling Wireguard? Could it be related to ipv6?

 

No ideas. IPv6 is working fine on physical interfaces here.

 

Containers or virtual machines are totally unsupported and not recommended. They have various problems for realtime application responsiveness and direct hardware access.

 

[trs]

Quote

Containers or virtual machines are totally unsupported and not recommended.

 

I'm actually directly using Fedora 30 now. I switched from Clear Linux thinking that would solve the issue, but it turned out to be unrelated. It's definitely something to do with the Wireguard interface and multicast. I was getting the segfault in Fedora as well, which is how I narrowed down the issue to Wireguard.

[Miska]

9 hours ago, trs said:

I'm actually directly using Fedora 30 now. I switched from Clear Linux thinking that would solve the issue, but it turned out to be unrelated. It's definitely something to do with the Wireguard interface and multicast. I was getting the segfault in Fedora as well, which is how I narrowed down the issue to Wireguard.

 

OK, if it is related to multicast, you could try modifying hqplayerd.xml config file by setting "interface" attribute in "upnp" element to a specific interface name instead of "auto". Other than that, there are no direct interface bindings by default. Even there, virtual interfaces should be skipped as they shouldn't have a "device" item in their sysfs directory.

 

How does "ifconfig" look like with Wireguard enabled?

 

[trs]

Thanks for the help. I tried setting interface="eno1" for the upnp element, but it didn't work. I also tried mcast_interface="eno1" on the network element (I'm using NAA) but still got the segfault.

 

I found if the Wireguard interface is up before I start the hqplayerd service, the segfault happens. If I bring up the Wireguard interface after hqplayerd is started, then there is no segfault. If I attempt to use hqplayerd as a upnp output however then there is a segfault.

 

Here is the output from ifconfig:
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 10.200.200.1  netmask 255.255.255.0  destination 10.200.200.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 45  bytes 15636 (15.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 46  bytes 32520 (31.7 KiB)
        TX errors 7  dropped 0 overruns 0  carrier 0  collisions 0
 

[Miska]

2 hours ago, trs said:

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420

 

OK, the interface is not even flagged as multicast capable.

 

I'll take a look if I can figure out what could be going wrong.

 

If you go to /sys/class/net/wg0 directory and "ls", how does it look like?

 

[trs]

Thanks for looking into this. Here is the output from ls /sys/class/net/wg0:

addr_assign_type    carrier_up_count   ifalias           operstate       speed
address             dev_id             ifindex           phys_port_id    statistics
addr_len            dev_port           iflink            phys_port_name  subsystem
broadcast           dormant            link_mode         phys_switch_id  tx_queue_len
carrier             duplex             mtu               power           type
carrier_changes     flags              name_assign_type  proto_down      uevent
carrier_down_count  gro_flush_timeout  netdev_group      queues
 

[Miska]

9 hours ago, trs said:

Thanks for looking into this. Here is the output from ls /sys/class/net/wg0:

 

I've found and fixed the problem for next release...

 

[trs]

12 hours ago, Miska said:

 

I've found and fixed the problem for next release...

 

 

Thanks, awesome support as always!

[guiltyboxswapper]

Using bubbleupnp with the native Rygel client, seeking into a track often causes HQP to stop responding.  Rygel eventually stops serving requests, meaning I need to restart HQP.  Source in this case is Qobuz.

 

Anyone else seeing such issues?