HQPlayer Linux Desktop and HQplayer embedded

[acatala]

Hi!

 

in a system with Roon Core and HQPlayer running both on headless Linux boxes, is it a better choice HQPlayer embedded over HQPlayer Desktop?

 

I guess that HQPlayer Desktop on a Linux box requires a Desktop software running but, on the other hand, HQPlayer embedded does not require it, so a few additional resources can be available for HQPlayer operation.

 

I am aware of the prices of both editions of HQPlayer, but this is not a variable that I am taking into account at this time.

 

[acatala]

Hello!!

 

I have recently built an Intel NUC7I7BNH and deployed Roon Core over Debian Linux Stretch. I chose an i7 processor because I was interested in running HQPlayer Embedded in this very NUC.

 

Before installing the trial version of HQPlayer Embbeded in the NUC, I thought I could install the trial version in a virtual machine. I use VM Fusion Pro 8.5 on macOS . I installed HQPlayer Embedded 4.3.1 and all its prerrequisites. The VM has a static IP address and its NIC is configured in bridge mode (not NAT). Roon Core is configured with a new HQPlayer output in the IP address of the VM.

 

For my inital tests I don't use the networkaudiod that is running over DietPi on a RPi3 B+, which is not detected by HQPlayer Embedded, but it is another chapter on which I will come back later. I am using ALSA output, so I connect the DAC with the laptop that runs the VM .

 

When I play music on Roon and select the HQPlayer Embedded as output, the DAC reacts and changes its bitrate, but the music does not play and Roon show the error message: "Transport: Roon lost control of audio device". I also get several error messages in the VM like this:

 

usb 2-2: timeout: still x active urbs on EP #i

 

I don't know if the problem is due to running HQPlayer Embedded in the VM.

 

 

[acatala]

2 hours ago, Miska said:

 

Utilizing USB from a VM is likely going to be pain and suffering, especially for something like audio playback. You may have better success with NAA....

 

Thanks @Miska

 

I was going from easy to difficult, or at least I thought so.

 

I have a RPi3 B+ with DietPi and NAA running on it, but the VM can not see the NAA. Is there any configuration that I should apply to the NAA in order to be visible to HQPlayer Embedded in the VM?

 

Maybe you are going to suggest me that I should install the NAA image for RPI. If so, I will.

 

[acatala]

@Miska, is there any HQPlayer Embedded manual besides the readme file in /usr/share/doc/hqplayerd?

 

I miss that, so much.

 

[acatala]

On 9/15/2018 at 6:14 PM, Miska said:

 

Utilizing USB from a VM is likely going to be pain and suffering, especially for something like audio playback. You may have better success with NAA....

 

Hi @Miska.

 

I detected a problem with the Ethernet port of the RPi3, because of this, HQPlayer Embedded did not find any NAA. After using your NAA image instead of DietPi, I was not able to detect de NAA either, so I installed the microSD in another RPi3, the one I currently use as Roon Bridge with DietPi, and.. voila!! Now it works.

 

Now HQPlayer Embedded in the VM detects de NAA and I can play Roon to HQPlayer Embedded. The configuration is easy, it is just a matter of find your desired configuration.

 

Until I have my failed RPi replaced, I guess I could install both Roon Bridge and NAA in the same instance of DietPi as long as I execute just one of them at a time. So I could try and compare Roon vs Roon + HQPlayer Embedded.

 

Thanks!

 

[acatala]

@Miska, is there a way in HQPlayer Embedded to configure a discriminator in order to upsample or not depending on certain signal characteristics like bit depth and/or sample frequency?

 

I was thinking of HQPlayer Embedded fed from Roon. It would be nice if it could upsample to DSD128/256 if the source is CD quality and not upsample if the source is 24 bits / 192 kHz, for example.

 

i was thinking of this feature just in case Qobuz be integrated with Roon in the months to come. Qobuz can stream some pieces of music in 24 bits/192 kHz format and others in 16 bits/44,1 kHz. So if I select HQPlayer Embedded as an output, it would be nice that HQPlayer Embedded could be configured to upsamble to DSD or not  depending on the source.

 

If this feature is not possible at this time. Do you think it could be interesting to implement in future releases?

 

Thanks!!
 

[acatala]

10 hours ago, Miska said:

 

You can set different filter for the two cases. But I fail to see point why one would want to upsample RedBook to DSD and not hires PCM!? You should always send to the DAC the format it performs best at / has least processing applied, regardless of the source format.

 

 

Good point, @Miska. How could I know what format is this? In my case, I use the embedded DAC in my Rotel RC-1590 pre-amplifier. Its specifications claims that he uses an AKG Premium 32 bits / 768 kHz DAC chip but in the user manual only the 24 bits / 192 kHz format in the PC-USB interface is declared. But I can not know if it has least procressing applied with 24 bits / 192 kHz PCM or with DSD128. I have no futher information.

 

My point was knowing if different upsamples could be applied depending on the source characteristics. It seems that this is possible.

 

If my Roon library, or future Qobuz integration, has RedBook music and HiRes music I was thinking of upsample RedBook to DSD and lefting HiRes untouched. Just and idea, I don't know if a stupid one, but I thought about it.

 

[acatala]

Thanks @Miska, I will try different combinations. Nice advices on your part!.

 

[acatala]

I have installed hqplayerd 4.6.1 on a Debian 9.6 Linux box with no problem at all. I also have a RPi 3 running DietPi 6.17.12 with networkaudiod 3.5.5. 

 

I miss a user manual specific to HQPlayer Embedded so I had to pick up information here and there. I discovered that I could set a environment variables in order to configure networkaudiod. I am including this environment variables in the file /etc/default/networkaudiod. I have set these variables:

 

NETWORKAUDIOD_IPV6=0

NETWORKAUDIOD_NAME=dietpi_naa

NETWORKAUDIOD_LOGFILE=/tmp/networkaudiod.log

 

With these variables. When I start hqplayerd I can read in the log file /tmp/hqplayerd.log that hqplayerd has discovered the NAA, but this NAA is not listed in the combobox in the configuration web page unless I edit the /etc/hqplayer/hqplayerd.xml and write the name of the NAA (dietpi_naa) in the network label. Is this correct?

 

When finally It seems that every single piece of software is able to stablish communications: Roon Core with HQPlayer Embedded and HQPlayer Embedded with NAA, the integrated DAC in my Rotel RC-1590 does not receive any information.

 

What am I missing?

 

I am disabling IPv6 in the NAA and in the configuration of the NAA in the HQPlayer Embedded web page. I have read in the /usr/share/doc/hqplayer/readme.txt.gz file there is a environtment variable (HQPLAYERD_IPV6) that can be set to 0 disable IPv6 for the hqplayerd. So I have set it in /etc/default/hqplayerd.

 

In a post I have read that @Miska recommended use IPv6 even when there is no IPv6 configured devices in the network.

 

 

 

[acatala]

6 hours ago, Miska said:

 

Is the device setting for NAA correct too? There are two items for NAA, one is name of the NAA and another is device ID behind a particular NAA. So you can have multiple NAA's each having multiple DACs on your network.

 

 

Why on earth do you disable IPv6? Usually NAA discovery works much better with IPv6. And you cannot even really completely disable IPv6 in HQPlayer Embedded. Essentially that environment only disables it for NAA support, but not for other functionalities.

 

 

Yes, because it has nice auto-configuration for local networks. You don't need to do anything. I would assume DietPi also supports IPv6? Also remember that IPv6 is backwards compatible with IPv4. Entire IPv4 address space is mapped into IPv6 address space as a special subnet. This is possible because IPv6 has really huge address space (128-bit) compared to IPv4 (32-bit).

 

 

Thanks for your reply @Miska

 

I have not set any device ID for the NAA. I have not seen that piece of information in any manual. I have found all the info I have searching in forums. Is there a place where all the configuration stuff for the NAA is listed?

 

I have disabled IPv6 because after the default configuration did not work and I missed the before mentioned manual, I started trying configurations until I found a set that worked or at least I thought so. I will come back to IPv6.

 

DietPi supports IPv6. I have not special interest in running DietPi, so I could also run your NAA image for Raspberry Pi 3 v3.5.5. I guess this would be a better option, right?.

 

I appreciate your on-line support. Thanks a lot.

 

[acatala]

15 minutes ago, Miska said:

 

It is certainly documented there, under section 1.3.3 discussing "network" sub-element.

There are both "address" and "device" attributes listed.

 

I have read the readme file. It is a kind of reference manual. It says:

 

"Attribute: address

Name of the remote network audio adapter to be used.

...

Attribute: device

Remote device name."

 

OK, how do the name of the remote networkaudiod is set? I guess by means of NETWORKAUDIOD_NAME environment variable. Found in a forum. I don't know if there is another way.

 

Remote device name. Is it found in the /tmp/hqplayerd.log file? Is there any other way of finding it?

 

Should this info be manually written in /etc/hqplayer/hqplayerd.xml? Is it selfconfigured after discovery?

 

I am finding out some of this information on my own, but I don't know if every step I make is the right one. Like the IPv6 disabling that I did.

 

 

15 minutes ago, Miska said:

 

If you envision that you don't need extra things that the DietPi provides and just want a minimal NAA image, then it is likely better.

 

Note though that RasPi can be a bit tricky at any higher sampling rates, because it has both ethernet and USB type-A connectors on the same USB bus. This tends to clause clicking or other side effects on USB audio. It works fine up to 192k PCM though through it's I2S connection to audio boards like HifiBerry.

 

 

I will use RPi3 with PCM 192k and DSD128 tops. With bare Roon works fine, so far. I could install the NUC7iBNH close to the DAC but I'd rather keep them separate just for fan noise avoiding. Just in case ?

 

 

 

[acatala]

7 hours ago, Miska said:

 

If the NAA endpoint is Linux-based, it is ALSA device id. You can find these with "aplay -l". So usually it would look like "hw:CARD=xxx,DEV=0" where value for the CARD is the short name listed by aplay.

 

 

Hi again @Miska.

 

I have managed to run HQPlayer Embedded with a remote NAA. It turns out that my DietPi did not support IPv6. That's is why HQPlayer Embedded did not fin any NAA at startup and it did when I configured NAA by disabling IPv6. I will clone the microSD and will try your NAA image. Now that I know how to run it.

 

Your advice for setting up the device name worked fine. Thanks!!!

 

As you said, I can hear pops while the music is playing, but at this time I have no more time for tests. My main issue right now is solved. I will go on with more test at weekend.

 

Thanks a lot for your information!!

 

[acatala]

I don't know if this is the right place for this question. I apologize if not.

 

Linux and macOS boxes use DoP when streaming DSD to a DAC. Is there a upper limit when using DoP (DSD128, DSD256, DSD512, etc.) or on the other hand does it depend on the DAC device?

 

If using a DAC that supported a DSD stream upper than the one it could be achieved by means of DoP, but using ASIO drivers, I guess we should run the NAA over Windows. So, we should add the cost of a Windows License to the hardware cost unless there were a version of windows for this cases. A cheap one, right?

 

[acatala]

2 hours ago, acatala said:

Linux and macOS boxes use DoP when streaming DSD to a DAC. Is there a upper limit when using DoP (DSD128, DSD256, DSD512, etc.) or on the other hand does it depend on the DAC device?

 

 

I answer my self this question: It depends on the DAC device.

 

[acatala]

54 minutes ago, Miska said:

 

That is all good because you need to select DAC too. Whenever it cannot access DAC it will redirect you to the config page, trying to hint "check your config".

 

 

That's clever, @Miska!! Sometimes I wondered why HQPlayer Embedded remained in the config page again and again ?

 

Definitely, a user manual with all the information spread over this forum is needed. There are lots of information around that would worth it being together.

 

I installed your NAA image for Raspberry Pi on a RPi 3 B+ and used IPv6 for NAA discovery. It works fine, as you said. When I streamed in DSD128 format, pops can be heard, as you also said. I tested too, connecting the NUC (Roon Core + HQPlayer Embedded) directly to the DAC and it sounded perfect. I will keep testing in the weeks to come. By the way, I have purchased a license even I have not ended my tests. I find that the product is nice and you are easily available, so it is fine for me ?

 

I used for my test ASDM7 modulator and poly-sinc-xtr-mp-2s filter. It sounded fine, but the NUC7I7BNH processor worked close to 100% as seen from top command.

 

I will consider alternatives:

 

Connecting the NUC with Roon + HQPlayer Embedded to DAC with USB

Using another NAA different from RPi3

Using a future new more powerful NUC (or similar) and move HQPlayer Embedded there (I am aware that there is a change in the fingerprint, but this is not a short term alternative right now) and connecting to the DAC directly.

 

We'll see.

 

Thanks Jussi!!

[acatala]

I have been running a few tests this afternoon with HQPlayer Embedded deployment. I am running Roon Core and HQPlayer Embedded over Debian Linux 9.6 on a Intel NUC7I7BNH. 

 

The Intel NUC is not located in the same room as the DAC (Rotel RC-1590 preamp. with integrated DAC), so I am using a Raspberri Pi 3 with DietPi and RoonBridge. I can stream over FastEthernet from Roon Core at DSD128 rate without problems. While Roon Core is upsampling from PCM (RedBook) to DSD128, "top" command shows a use of processor of 40%-50%.

 

I also have a Raspberri Pi 3 B+ that I would like to use as NAA for HQPlayer Embedded, but @Miska said me that the Raspberry could not work fine as NAA for streams at upper rates (PCM192, DSD64, DSD128, etc). I have configure HQPlayer Embedded to upsample to DSD64, DSD128, PCM384, PCM192 and PCM96. I only can hear the music without pops at PCM96.

 

Allo USBridge could be a nice alternative but I find it pricey. Would Asus Tinker Board be a valid alternative to Raspberry Pi 3 B+ as hardware for running NAA?

 

I could use in the future another Intel NUC in order to run HQPlayer Embedded directly attached to the DAC as suggested by @Miska, but when I upsample to DSD128 using poly-sinc-xtr-mp-2s filter with HQPlayer Embedded the NUC7I7BNH reaches a CPU use close to 100%, is that a normal value for that CPU/upsample combo?

 

Thanks in advance for your thoughts.

 

[acatala]

3 hours ago, shadowlight said:

I have not researched this at all or tried it myself so I could be completely wrong about this, but have you thought about using the USB DAC and WiFi on on the RPi 3?  As Miska has mentioned the ethernet and USB share resources but I believe the WiFi is completely set of bus.

 

Actually, I have. Yesterday, I installed DietPi and networkaudiod. When I was configuring DietPi, I went to the Wi-Fi config menu and it told that Wi-Fi interface was on, but it was unable to find drivers for it. I will try again tomorrow. Perharps there is a problem with this RPi 3 B+ unit. It would be a solution for me because the RPi 3 B+ is going to stay a couple of feet from the AP.

 

3 hours ago, shadowlight said:

 

Personally, if I was in your shoes I would just get another low powered Intel NUC type of device and install Linux if your system supports it or Windows if Linux support is not available.

 

That is another option I was thinking about: Using a low cost NUC (I3, Celeron, previous generation, etc) that would run networkd daemon on Linux. But as "an alternative to this alternartive" I thought of using a "full" NUC that would run HQPlayer Embedded directly attached to the DAC, as far as there were no problems with fan noise. That's why I was thinking of an NUC I5 with fanless case, but I was worried about the CPU use with the NUC7I7 when upsampling to DSD128.

 

[acatala]

53 minutes ago, Miska said:

 

This is what I use as a NAA with my bootable image:

https://up-shop.org/home/81-up-gws01w4g-memory32g-emmc-boardwo-vesa-plate.html

I have listed also some other recommended NAA hardware on the web page. It has also WiFi available, but it is USB-connected, so if you need WiFi, something else may be better suited where WiFi is attached to mPCIe, like:

https://www.logicsupply.com/eu-en/cl100/

https://www.logicsupply.com/eu-en/cl200g-10/

These have the DHXA-222 wireless card available:

https://www.logicsupply.com/dhxa-222/

I have not personally tested these with WiFi, only the CL-100 through Ethernet. But that wireless is supposed to work with ath9k driver on Linux too. Probably corresponding Intel wireless cards would work too.

 

I did look at them yesterday. UP Gateway could be a candidate for me too. The other NAA devices from your recomended hardware list are too pricey for my needs, I mean Sonore and SOtm devices. You don't tell in your web anything about Asus Tinker. I don't know if it isn't recommended or just it hasn't been tested.

 

53 minutes ago, Miska said:

I consider any Core-based NUC overpowered for a NAA... I think Atoms, or the low power Celeron/Pentium branded models are better suited for the purpose.

 

I also consider it overpowered for a NAA. Because of that I thought that in case to use a Intel NUC, I would choose one that could run HQPlayer Embedded like you do. It is a more expensive alternative, but an alternative after all.

 

53 minutes ago, Miska said:

 

NUC7i7 is just ultra-book category low power dual core CPU. With it, you can turn off "Multicore DSP" in HQPlayer settings. I have one for running my measurement rig, but I have not done practically any testing with it for HQPlayer use because it has too loud fan for my taste (NUC7i7BNH model to be exact). I purchased it just because it is small and supports 4k through HDMI 2.0.

 

 

I have updated multicore parameter from "auto" to "0". I am not at home, I did it with the SSH client. I will test it tomorrow.

[acatala]

@Miska, this afternoon I have been playing with the Raspberry Pi 3 B+ again. I was trying to find out why the wireless interface was unavailable. Finally I have disabled and enabled back the interface and it started working. After that I have configured it.

 

The NAA now worked wireless and the sound quality has improved. Now there are very very few pops (almost no pops). My buffer configuration was set to 0 ms (default). I don't know if setting 50 or 100 ms would be better.

 

The NAA is very close to the AP, less then 2 feet, so the signal strength is high. I need to test the wireless link reliability, but definitely the Raspberry Pi 3 B+ as NAA must work wirelessly.

 

By the way, I was streaming in DSD128 format and the Raspberry Pi 3 B+ running Diet Pi.

 

Definitely I will need another NAA if I want to go wired. I find interesting the UP Bridge that you recommend .

[acatala]

6 hours ago, diecaster said:

 

Have you compared the Up Board Gateway to something like the ultraRendu?

 

At the first glance, there is an obvious difference: Up Board costs $189 and ultraRendu costs $875. Besides, I have not an oscilloscope in my ears. I am having a hard time to justify the difference in price.

[acatala]

On 11/27/2018 at 5:45 AM, acatala said:

I was worried about the CPU use with the NUC7I7 when upsampling to DSD128.

 

I answer myself: I changed view in top to threads view and now the CPU use when I upsample to DSD128 is around 50%/thread. That's more realistic.

 

[acatala]

9 hours ago, Em2016 said:

I may try wireless (via USB adapter) this weekend, just out of curiosity. I'm running DietPi x86_64 version on my Up Board Gateway (installed on the internal eMMC but boots to ramdisk) and it may allow USB-WiFi adapter. I'll find out.

 

Please, share your wireless tests with us when you have the results. My wireless test with the Raspberry Pi 3+ has been fine, I just need to test how reliable it is.

 

Quote

Of course for simple wired connection, you can use Jussi's USB bootable images (either the standalone NAA image or HQPe image works fine as NAA too).

 

You talk about a USB bootable image, I guess you are installing the NAA or HQPlayer Embedded (unlicensed) + NAA in a USB memory and then boot from it without using the eMMC drive. I guess that as an alternative a Debian Linux can be installed in eMMC drive and after that install the networkd software, right?

 

[acatala]

Sure @Em2016. For now, I am testing alternatives with Raspberry Pi 3 B+, but I am willing to try UP Gateway too. I will let you know the results.

 

[acatala]

New test with Raspberry Pi 3 B+ with DietPi and NAA, using the wireless interface.

 

I have set the Buffer Time parameter to 50 ms and 100 ms. In both cases, the sound was fine with no artifacts. I also powered the Raspberry Pi 3B+ from a USB power bank instead of AC supply.

 

As in previous tests, the stream was DSD128, with poly-sinc-xtr-mp-2s filter and ASDM7 modulator.

 

[acatala]

I asked a few time ago a question in the DAC forum ( Click sound at the beginning of DSD playing ) regarding the click sound that my DAC makes when it changes its mode, from PCM to DSD and viceversa. This sound is higher with HQPlayer Embedded than with Roon. I guess this has nothing to do with both pieces of sofware but with the DAC (or the AKM AK4495 chip itself). Right ?

 

Could that starting/ending noises damage the loudspeakers?