HQPlayer Linux Desktop and HQplayer embedded

[benkit]

Hi Jussi,

     I have couple questions for HQP embedded  version.

     1) Will possible HQP embedded install onto intel x86 machine in one short?   Seem install HQP+OS image, booting

            and go without any Linux installation.

     2) What is linux OS recommended for HQP smooth and stable in case impossible for item 1)

     3) What is OS and device recommended for  NAA running if using HQP embedded?

    4)  What is differently license between embedded 4.x for Linux and embedded 4.x classic shop/reseller?      

[asdf1000]

Hi Jussi @Miska

 

Have you seen this , which apparently supports Chromecast audio?

 

https://github.com/ejurgensen/forked-daapd

 

 I use HQPe as a UPnP renderer but could you look at HQP Embedded becoming a Chromecast audio endpoint?

 

It would open the door to the native apps of basically every streaming service except Apple Music.

 

Since Qobuz, Deezer, Tidal, Google Music, Amazon Music, Soundcloud, Pandora and Spotify native apps all support Chromecast.

 

For Qobuz, it would mean support for 24/96kHz streaming since Chromecast supports 24/96...

 

 

[simonklp]

1 hour ago, Miska said:

 

You have IPv6 enabled for the network interface? You don't need to configure it in any way, IPv6 has nice serverless auto-configuration.

 

I assume this is stock Windows 10 with latest updates and without running any special "optimization" applications...

 

 

I had tried both IPv6 and IPv4 setting. But it didn't work for both cases.

 

Although the OS of NAA is WS 2016 Core with AO, I had checked that it works without problem for latest version of HQPlayer Desktop on Linux.

[Miska]

20 minutes ago, simonklp said:

I had tried both IPv6 and IPv4 setting. But it didn't work for both cases.

 

Although the OS of NAA is WS 2016 Core with AO, I had checked that it works without problem for latest version of HQPlayer Desktop on Linux.

 

Both Desktop and Embedded use the same code to talk to NAAs, so there's something else to it...

 

[Miska]

34 minutes ago, Em2016 said:

Have you seen this , which apparently supports Chromecast audio?

 

https://github.com/ejurgensen/forked-daapd

 

I think that supports only output to a Chromecast device.

 

34 minutes ago, Em2016 said:

I use HQPe as a UPnP renderer but could you look at HQP Embedded becoming a Chromecast audio endpoint?

 

Chromecast uses DRM that is built into hardware of Chromecast devices. So it is not so straightforward...

 

However, using Google's Chromecast Audio dongle and Toslink connection from it to HQPlayer Embedded works fine for me.

 

[asdf1000]

2 minutes ago, Miska said:

However, using Google's Chromecast Audio dongle and Toslink connection from it to HQPlayer Embedded works fine for me.

 

Noted. Skipping TOSlink (and it's jitter) in the chain would be preferable for most I would assume.

 

 

[Miska]

54 minutes ago, benkit said:

     1) Will possible HQP embedded install onto intel x86 machine in one short?   Seem install HQP+OS image, booting

            and go without any Linux installation.

 

Yes, you just boot the image and you are ready to go (you'll need to set management username+password first though).

 

55 minutes ago, benkit said:

2) What is linux OS recommended for HQP smooth and stable in case impossible for item 1)

 

Currently supported ones are Ubuntu Server with my custom kernel (most recommended), minimal Debian 9 (Stretch), Fedora 28 minimal install.

 

56 minutes ago, benkit said:

3) What is OS and device recommended for  NAA running if using HQP embedded?

 

For NAA hardware, you can see "recommended hardware" section on my HQPlayer Desktop web page.

 

57 minutes ago, benkit said:

4)  What is differently license between embedded 4.x for Linux and embedded 4.x classic shop/reseller?

 

Just different web interface, no difference in license. The latter provides better interface for resellers.

 

[Miska]

2 minutes ago, Em2016 said:

Noted. Skipping TOSlink (and it's jitter) in the chain would be preferable for most I would assume.

 

Jitter doesn't matter at all in this case... As long as data is correct. HQPlayer Embedded can withstand input jitter to several hundred milliseconds range. Toslink will always have much less jitter than streaming Tidal over internet...

 

Input hardware will put more limits to the jitter before dropping data, but the RME HDSPe AIO has very flexible and good DPLL.

[asdf1000]

11 minutes ago, Miska said:

Jitter doesn't matter at all in this case... As long as data is correct. HQPlayer Embedded can withstand input jitter to several hundred milliseconds range.

 

But the TOSlink source (Chromecast Audio and the MiniDSP Streamer combination) would now responsible for the timing, no?

 

Even if everything downstream is ethernet and USB, the weakest link is the TOSlink in the chain?

 

The DAC's incoming jitter is now dependant on the jitter of the Chromecast + MiniDSP Streamer source?

 

How does HQP Embedded correct for timing errors of the SPDIF source?

 

[Miska]

3 hours ago, Em2016 said:

But the TOSlink source (Chromecast Audio and the MiniDSP Streamer combination) would now responsible for the timing, no?

 

No, there's no timing info used from it, only data is used and sampling rate is assumed to average to the reported one over long period of time.

 

3 hours ago, Em2016 said:

Even if everything downstream is ethernet and USB, the weakest link is the TOSlink in the chain?

 

No, it doesn't make anything any weaker...

 

3 hours ago, Em2016 said:

The DAC's incoming jitter is now dependant on the jitter of the Chromecast + MiniDSP Streamer source?

 

No, DAC's clock runs at it's own pace and has no relation whatsoever to the source. Both input and output are clocked independently and asynchronously. So you can have input at 44.1 kHz and output at 48k x512 DSD.

 

If you want automatic rate switching, then it is better to use the RME card instead. Otherwise you will have to change the rate from HQPlayer web interface for now (because USB Audio Class has completely idiotic way to manage sampling rate).

 

3 hours ago, Em2016 said:

How does HQP Embedded correct for timing errors of the SPDIF source?

 

By ignoring the timing altogether... As long as the receiving hardware can lock into the source and provide data, everything is good. The clock that comes over Toslink is just used to receive the data in bit-perfect way and report the rough sampling rate (for example 44.1 kHz). But the actual generated clock is not output anywhere and doesn't reach HQPlayer. If the jitter becomes so bad that receiver loses lock, then you will have a drop-out in the audio.

[simonklp]

4 hours ago, Miska said:

 

Both Desktop and Embedded use the same code to talk to NAAs, so there's something else to it...

 

 

One point to note is that when the networkaudiod 3.5.4 is running and HQPlayer Desktop or HQPlayer Embedded is started, there is a message of "Network QoS functionality not available" (see attached photo)

 

Is it normal and does it affect the linking between networkaudiod and HQPlayer Embedded?

[Miska]

3 hours ago, simonklp said:

One point to note is that when the networkaudiod 3.5.4 is running and HQPlayer Desktop or HQPlayer Embedded is started, there is a message of "Network QoS functionality not available" (see attached photo)

 

Is it normal and does it affect the linking between networkaudiod and HQPlayer Embedded?

 

It is not normal, but it doesn't affect that part. It only affects performance of the NAA. If this is some Server version of Windows, you need to install the missing component (see relevant discussion in this thread). If it is stock Windows 10, 8.1 or 7 it should be installed by default and something is wrong if it isn't.

 

[asdf1000]

8 hours ago, Miska said:

 

By ignoring the timing altogether... As long as the receiving hardware can lock into the source and provide data, everything is good. The clock that comes over Toslink is just used to receive the data in bit-perfect way and report the rough sampling rate (for example 44.1 kHz). But the actual generated clock is not output anywhere and doesn't reach HQPlayer. 

 

Thanks Jussi!

 

The way you describe it is very similar to Ted Smith’s explanation  for jitter elimination with the DS DAC.

 

Is this unique to HQPe or just how the USB interface (which ‘feeds’ HQPe) works in general?

[Miska]

1 minute ago, Em2016 said:

Is this unique to HQPe or just how the USB interface (which ‘feeds’ HQPe) works in general?

 

It is by HQPlayer design, and the way it is handled is in HQPlayer's design. But as concept also by necessity because asynchronous USB anyway has the master clock of output.

 

[luisma]

On 5/21/2018 at 1:48 PM, Miska said:

 

Yes, you can scan local content to HQPlayer's library using the web interface. Then you just point HQPDcontrol at HQPlayer Embedded machine.

 

 

Bare minimum Ubuntu Server with lowlatency kernel (or my custom one), or alternatively bare minimum Debian 9 with realtime kernel (or my custom one). These will have only simple text mode console and no graphical output.

 

Hi Miska;

 

I would like to run Roon and HQPe in the best possible efficient environment. Which image should I use? yours? or a standard minimal distribution.

I'm very familiar with Linux so anything you believe is "efficient for both" will do

 

ROCK I guess is off the table

 

 

[luisma]

Notice you recommend this Ubuntu Server with my custom kernel (most recommended) but if that's the case will that be best for Roon as well sharing the same NUC, I'm planning to run the OS native not under Windows

 

[Miska]

This is also what I do on two servers at the moment; use the standard minimal Ubuntu Server as a starting point, nothing else installed except SSH server. Then install my 4.14 kernel build which is optimized for this use case unlike the one installed as standard on Ubuntu. Then install libgmpris and hqplayerd packages and then fetch the missing dependencies with "apt install -f". That's pretty much it. Just set the configuration username+password with "hqplayerd -s username password" and restart hqplayerd service.

 

Network configuration is straightforward through /etc/network/interfaces file.

 

This should be good basis for Roon Core as well. Putting anything extra on my bootable images is tricky at best, so they are best as-is.

[luisma]

2 hours ago, Miska said:

This is also what I do on two servers at the moment; use the standard minimal Ubuntu Server as a starting point, nothing else installed except SSH server. Then install my 4.14 kernel build which is optimized for this use case unlike the one installed as standard on Ubuntu. Then install libgmpris and hqplayerd packages and then fetch the missing dependencies with "apt install -f". That's pretty much it. Just set the configuration username+password with "hqplayerd -s username password" and restart hqplayerd service.

 

Network configuration is straightforward through /etc/network/interfaces file.

 

This should be good basis for Roon Core as well. Putting anything extra on my bootable images is tricky at best, so they are best as-is.

Thanks, where can I get your kernel build? your site?

 

[luisma]

@Miska you agree that Linux (performance and SQ wise) is the way to go right?

 

[simplythere]

Hello, I am using HQplayer(4.2, updated) embedded with Sonictransporter(2.6, updated)

 

I am trying to do room correction with REW. I got the filter as wav for left and right and set them in convolution in Hqplayer. Then NOTHING happened. I have enabled the convolution for sure. 

 

Then, I do it once again with both speaker and this time, I read the EQ filter reading and input them manually in Roon DSP EQ. Then I measure the the response. And the fq response is effective. (The green line)

 

Is convolution of HQplayer embedded working for REW? I hope someone can share their successful experience. Thank you!

[benkit]

Hi Jussi,

     Do you have any  update for  HQP embedded instal guide?  I have the HQPlayer embedded install guide V.0.5 that may be out date.

Have you any opinion for audiolinux OS that already HQPe  bundle onto it?  It just only purchase the license that's all .  Any  test  with sound quality and latency .

 

Thank you

 Benkit 

[Miska]

45 minutes ago, simplythere said:

Hello, I am using HQplayer(4.2, updated) embedded with Sonictransporter(2.6, updated)

 

I am trying to do room correction with REW. I got the filter as wav for left and right and set them in convolution in Hqplayer. Then NOTHING happened. I have enabled the convolution for sure. 

 

Then, I do it once again with both speaker and this time, I read the EQ filter reading and input them manually in Roon DSP EQ. Then I measure the the response. And the fq response is effective. (The green line)

 

Is convolution of HQplayer embedded working for REW? I hope someone can share their successful experience. Thank you!

 

It should be working fine. Did you check the log if it gets loaded and initialized properly?

 

[Miska]

7 hours ago, luisma said:

@Miska you agree that Linux (performance and SQ wise) is the way to go right?

 

For sound quality OS shouldn't matter much. Performance-wise Linux is best. Some features are different, like support for native DSD without DoP and such.

[Miska]

20 minutes ago, benkit said:

     Do you have any  update for  HQP embedded instal guide?  I have the HQPlayer embedded install guide V.0.5 that may be out date.

 

Hmmh, install guide? There's something on my web page, and in the readme.txt included in hqplayerd package.

 

21 minutes ago, benkit said:

Have you any opinion for audiolinux OS that already HQPe  bundle onto it?  It just only purchase the license that's all .  Any  test  with sound quality and latency .

 

I have never tried it, so I cannot comment on that...

[simonklp]

16 hours ago, Miska said:

 

It is not normal, but it doesn't affect that part. It only affects performance of the NAA. If this is some Server version of Windows, you need to install the missing component (see relevant discussion in this thread). If it is stock Windows 10, 8.1 or 7 it should be installed by default and something is wrong if it isn't.

 

 

If I didn't install the missing components of QWAVE for server version of Windows, the networkaudiod would have not started already. So, it's strange to me that even after successful installation of QWAVE and starting up of networkaudiod, there is still issue of "Network QoS not available".