HQPlayer Linux Desktop and HQplayer embedded

[shadowlight]

2 hours ago, Miska said:

 

To make such cases easier, I'm also building the full bootable OS image of Embedded. So that getting it up and running would be as easy as possible. OS on that image is optimized for this particular purpose and is very streamlined and minimal. For more flexibility, and possibility for such things as ssh, I recommend building it based on those normal distributions you mentioned. Nowadays, also Fedora is supported for Embedded and it also allows minimal install (smaller than server install).

 

Input and UPnP features are only available on Embedded.

 

Having the bootable image that is streamlined would be great and make it easier for folks to leverage embedded.

 

One reason that I default to Debian is that I find it's net install to create the smallest foot print compared to Ubuntu.  As long as you keep putting out your custom kernel I will stick with Debian even though you development system is Ubuntu based :).  I will have to try Fedora some day.

[asdf1000]

Hi @Miska

 

I'm demo-ing the new iFi Pro iDSD.

 

With your HQPe image and direct USB ALSA connection to the Pro iDSD I can play native DSD512 (up-sampled) fine.

 

But when I play from HQPe to NAA on USBridge I get static with native DSD (any rate) - but DoP is ok.

 

Is there a new patch Pro iDSD that you implemented in HQPe v4.2.1 that maybe Dietpi hasn't patched yet?

 

My previous micro iDSD had no issues with USBridge NAA at DSD512 - so not sure what's changed with the new Pro iDSD DAC?

 

See below for USBridge output.

 

Any advice you can give me based on the above, that I can pass to DietPi and Allo? So I can get back to use NAA on USbridge which has been rock solid for me with micro iDSD and Pro-Ject S2 DAC, even at DSD512.

 

 

It can't be the Pro iDSD DAC itself since it works fine with Native DSD512 with HQPe direct USB ALSA connection.

 

Cheers

 

[Johnseye]

@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.  

[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

 

[Johnseye]

9 minutes ago, luisma said:

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

 

 

Yes, it is a white noise type of sound.  Thanks for the info, I'll check the libasound2 packages.

[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

 

[asdf1000]

On 8/24/2018 at 11:49 AM, Em2016 said:

Hi @Miska

 

I'm demo-ing the new iFi Pro iDSD.

 

With your HQPe image and direct USB ALSA connection to the Pro iDSD I can play native DSD512 (up-sampled) fine.

 

But when I play from HQPe to NAA on USBridge I get static with native DSD (any rate) - but DoP is ok.

 

Is there a new patch Pro iDSD that you implemented in HQPe v4.2.1 that maybe Dietpi hasn't patched yet?

 

My previous micro iDSD had no issues with USBridge NAA at DSD512 - so not sure what's changed with the new Pro iDSD DAC?

 

See below for USBridge output.

 

Any advice you can give me based on the above, that I can pass to DietPi and Allo? So I can get back to use NAA on USbridge which has been rock solid for me with micro iDSD and Pro-Ject S2 DAC, even at DSD512.

 

 

It can't be the Pro iDSD DAC itself since it works fine with Native DSD512 with HQPe direct USB ALSA connection.

 

Cheers

 

 

An update on the above @Miska :

 

I've been working with RoPieee developer and he noticed you use Altset = 3 with the Pro iDSD and that probably explains the issue with RoPieee/DietPi/Roons having static with native DSD.

 

Does that affect compatibility with the older micro and nano iDSD models?

 

[asdf1000]

On 5/24/2018 at 3:53 PM, Em2016 said:

Help @Miska

 

I installed your x64 NAA image to USB for my LattePanda.

 

But HQPe is unable to see the NAA (connected to Pro-Ject S2 DAC).

 

Attached are screenshots:

 

 

 

 

Final screen on the NAA:

 

 

An update on my LattePanda !

 

Since I posted this in May, there has been a new NAA image and a BIOS update to LattePanda - I just noticed this now.

So I thought, what the heck, let's update both and try again.

And voila, NAA is running on LattePanda, powered by a USB3.0 port !

 

My DAC obviously doesn't need 5V bus power, which is why the 900mA is enough.

 

Now I need to observe if it's stable and reliable or has any funky behaviour. 

 

[Miska]

On 8/26/2018 at 11:08 AM, Em2016 said:

An update on the above @Miska :

 

I've been working with RoPieee developer and he noticed you use Altset = 3 with the Pro iDSD and that probably explains the issue with RoPieee/DietPi/Roons having static with native DSD.

 

Does that affect compatibility with the older micro and nano iDSD models?

 

I have improved the native DSD support in Linux kernel and the patches are already in recent kernels. These patches are of course also in the images I build. At most it affects compatibility with older models in a positive way.

 

Use of altsettings is up to the driver in Linux kernel, applications are not involved in this.

 

[Johnseye]

On 8/24/2018 at 8:09 AM, 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.  

 

@Miska any ideas on what the issue could be?

[Miska]

7 minutes ago, Johnseye said:

 

@Miska any ideas on what the issue could be?

 

Please compare the settings carefully. Same version on Windows and Linux should show very similar performance.

 

On Linux with ALSA backend, you may want to set "Buffer time" to for example 100 ms which is quite good starting point.

 

[asdf1000]

2 hours ago, Miska said:

I have improved the native DSD support in Linux kernel and the patches are already in recent kernels. These patches are of course also in the images I build. At most it affects compatibility with older models in a positive way.

 

Use of altsettings is up to the driver in Linux kernel, applications are not involved in this.

 

Ahh nice. So everyone else needs to catchup to latest kernels. Thanks Jussi !

 

[applesnowleo]

On 8/24/2018 at 2:24 PM, Johnseye said:

 

Yes, it is a white noise type of sound.  Thanks for the info, I'll check the libasound2 packages.

 

I am having this issue with the iDSD Pro from iFI on a SOTM SMS-200 Ultra, white noise on native, it does not affect the micro iDSD Black Label.

[asdf1000]

2 hours ago, applesnowleo said:

 

I am having this issue with the iDSD Pro from iFI on a SOTM SMS-200 Ultra, white noise on native, it does not affect the micro iDSD Black Label.

 

See @Miska's post, just a few posts above - needs latest Linux kernel for Pro iDSD.

 

[asdf1000]

9 hours ago, Miska said:

On Linux with ALSA backend, you may want to set "Buffer time" to for example 100 ms which is quite good starting point.

 

Hi Jussi, I noticed the ALSA backend initial values when I first installed Embedded is 100ms buffer and "24 bits" for DAC bits.

 

For iFi iDSD's, should we change that to 32 bits?

[Miska]

1 hour ago, Em2016 said:

Hi Jussi, I noticed the ALSA backend initial values when I first installed Embedded is 100ms buffer and "24 bits" for DAC bits.

 

For iFi iDSD's, should we change that to 32 bits?

 

No, the DAC chip supports only 24-bit while the USB interface is 32-bit. To avoid truncation and related distortion, it should be kept at 24-bit. This naturally only affects PCM output mode (affects only dither depth).

 

[asdf1000]

Hi @Miska

 

For users with HQP Embedded, what's the current simplest method to do room correct measurements and integrate results into HQPe?

 

And are you working on a better integrated solution, to make it easier for HQPe users to use? Maybe integration with Dirac Live? Or something else? Or your own integrated solution?

 

Some of the current software solutions seem quite complex. I know some people (in real life) using REW and others, but I have to wonder if they really know what they're doing, doing it the DIY way ? This frequency & time domain stuff is complicated stuff. Obviously you get it, but average Joe like me wants a solution that does it correctly. A bit like up-sampling software and why we choose HQPe over others (and even over our DAC's built-in digital filtering).

 

And are you a believer in only using digital room correction for <500Hz (or whatever number) and leaving the rest to room treatments ? Assuming someone is happy with their speakers of course.

 

Or are you ok with digital room correction all the way through the audioband?

 

Cheers!

[Miska]

5 hours ago, Em2016 said:

For users with HQP Embedded, what's the current simplest method to do room correct measurements and integrate results into HQPe?

 

Currently I recommend Acourate, REW or Audiolense.

 

5 hours ago, Em2016 said:

And are you working on a better integrated solution, to make it easier for HQPe users to use? Maybe integration with Dirac Live? Or something else? Or your own integrated solution?

 

At least not in short term, I see three other applications already providing the functionality. AFAIK, Dirac Live doesn't support Linux nor processing DSD the way I want (or even high PCM sampling rates). I want room correction to work natively at any imaginable sampling rate both PCM and DSD.

 

5 hours ago, Em2016 said:

And are you a believer in only using digital room correction for <500Hz (or whatever number) and leaving the rest to room treatments ? Assuming someone is happy with their speakers of course.

 

Room correction only reaches to about 500 Hz, anything above that is not really room correction anymore, but loudspeaker correction. I personally prefer to process only lowest frequencies to tame some room modes and leave higher untouched. Running digital cross-overs with corrections and such is another thing some people are doing and I find it interesting too.

 

[jmmbarco]

Hi everybody,

 

This is Jose Miguel and this is my first post in this thread or any other about hqplayer. A few days back, I finally decided to give a try, and I plan to build a Ubuntu 16.04.5 roon server + hqplayer embedded in a powerful machine whereas my current hard modded music server will act as naa into my usb interface, using Ubuntu 16.04.5 as well.

I have started in my test environment, consisting in a SMSL DAC (DSD512/PCM768), a standard i3 machine acting as roon+hqplayerd server and a laptop as naa to the dac.

 

So far, the best I have done is to "correctly" install Ubuntu 16.04, hqplayerd and roon server. Even connecting the dac to the server I was able to play tracks from roon>hqplayerd>dac.

Right now I am stuck at the second step that is connecting hqplyerd to naa>dac. They don't see each other via multicast, even with a direct cable between both. Using an naa image in the test laptop(naa), hqplayerd discovered the remote audio devices in naa.

 

In conclusion, I have some network issues but I suspect they are related with a problem in installation either in server or in naa. 

 

This is the process I have followed in hqplayer+roon server:

1. Install Ubuntu Server v16.04.5 using a USB pendrive. During the installa wizard I installed only SSH and basic server install and assigned a ipv4 static address to the server.

2. Update kernel to "lowlatency-lts-xenial" via apt-get

3. Update kernel to custom "linux-image-4.14.49-jl+_13_amd64" via dpkg -i

4. Update kernel to custom "linux-headers-4.14.49-jl+_13_amd64" via dpkg -i 

5. Install the following libraries: "libglib2.0-0, libflac8, libasound2, libasound2-data, libgomp1" via apt-get

6. Install custom library "libgmpris_2.2.1-4_amd64" via dpkg -i (downloaded from sonarnred)

7. Check dependencies via "apt-get install -f"

8. Install hqplayer "hqplayerd_4.2.1-13_amd64"  via dpkg -i (downloaded from signalyst)

9. Execute command "sudo hqplayerd -s hqpe hqpe"

 

After theses steps I can access to https://<static_ip>:8088/config and as I said before I was able to start playback connecting the dac locally.

 

This is the process followed in naa laptop connected to dac:

1. Install Ubuntu Server v16.04.5 using a USB pendrive. During the installa wizard I installed only SSH and basic server install and assigned a ipv4 static address to the naa.

2. Update kernel to "lowlatency-lts-xenial" via apt-get

3. Update kernel to custom "linux-image-4.14.49-jl+_13_amd64" via dpkg -i

4. Update kernel to custom "linux-headers-4.14.49-jl+_13_amd64" via dpkg -i 

5. Install the following libraries: "libflac8, libasound2, libasound2-data, libasound2-plugins, alsa-utils " via apt-get

6. Check dependencies via "apt-get install -f"

7. Install naa "networkaudiod_3.5.4-38_amd64"  via dpkg -i (downloaded from signalyst)

 

The result is that there is no devices available in Network Audio Backend in hqplyerd web settings. If I check hqplyerd log in /tmp/... it shows that does not find any network audio devices.

 

Comparing to the hqplyerd or naa images i have noticed some diferences in my installation:

- hqplyerd image show a br0 interface which I suppose its a bridged virtual connection containing the physical ethernet. Is this necessary??? Actually I thought these config could cause issues.

- in both server or naa, when I use the images i get messages in console about the diferent interfaces status that do not appear in my non-volatile installation.

 

I am almost sure that all these issues are related to the networking and the interfaces configuration. But I still haven´t found the reason.

 

Any help or advice will be very appreciated.

Thank a lot in advance and sorry for my cherokee english... ;))

Best,

JM

[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. 

 

 

[jmmbarco]

34 minutes ago, luisma said:

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. 

 

 

Hi luisma, yes I have checked, and both services, hqplayerd in server and networkaudiod in naa, are enabled and running....how do you configure your network interfaces? are you using static or dhcp? ipv4 or ipv6?

I plan to subscribe to tidal as well when i get this working.....if that ever happens.....

[jmmbarco]

52 minutes ago, luisma said:

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. 

 

 

When I run the naa image I get info messages in the console prompt about the interface status as if it went through different states which do not appear in my ubuntu install maybe although service is running it is not working properly...

[Miska]

2 hours ago, jmmbarco said:

Comparing to the hqplyerd or naa images i have noticed some diferences in my installation:

- hqplyerd image show a br0 interface which I suppose its a bridged virtual connection containing the physical ethernet. Is this necessary??? Actually I thought these config could cause issues.

- in both server or naa, when I use the images i get messages in console about the diferent interfaces status that do not appear in my non-volatile installation.

 

It is for the cases where the hardware has multiple network interfaces. Otherwise multicast routing becomes a nightmare. It also works around issue on systemd waiting forever on unconnected interfaces to become ready and thus preventing service from coming up.

 

Those messages are normal for bridge setup, it takes a while for the bridge (which works just like a switch) to learn MAC addresses on the interfaces and detect link status.

 

Frequently problem finding a NAA case has been multi-homed configuration where HQPlayer machine has multiple network interfaces and then multicasts are being routed to the wrong one.

 

[shadowlight]

@Miska, what are the differences between hqplayerd_4.3.0-14 and hqplayerd_4.3.1-15, since they were released a day apart?