HQPlayer Linux Desktop and HQplayer embedded

[asdf1000]

30 minutes ago, Miska said:

 

There are probably some crypto keys embedded inside the hardware that make it tricky. If Google has been competent enough on that, it is not easy to extract those. And I'm not sure if people have enough motivation to do it, given price of the CCA dongle...

 

 

Noted. But maybe the Linux community will be motivated to crack it, to avoid TOSlink?

 

Not for SQ issues but just because the TOSlink input will slowly disappear on DAC hardware?

 

Who knows how long CCA will exist with optical output too. Apple has ditched all optical now.. There's no Apple hardware with optical source in current production now. So shareport got even more useful than before.

 

For audio, Chromecast audio support is getting built into everything now. Receivers, wireless speakers, blu-ray players, TV's etc. Just need a WiFi/ethernet connection.

 

For video, HDMI and Chromecast video dongles will stick around for a long while still I guess.

 

[Miska]

45 minutes ago, Em2016 said:

Noted. But maybe the Linux community will be motivated to crack it, to avoid TOSlink?

 

Not for SQ issues but just because the TOSlink input will slowly disappear on DAC hardware?

 

Who knows how long CCA will exist with optical output too. Apple has ditched all optical now.. There's no Apple hardware with optical source in current production now. So shareport got even more useful than before.

 

Most of Linux community probably couldn't care less, they are not audiophiles. Afterall, they are fine with Pulseaudio too!  They are probably perfectly fine with the CCA's analog output... If it gets cracked it is more likely for the video features and less likely for audio. People at large are more interested on video. There are still audio codecs that ffmpeg project didn't bother to reverse-engineer.

 

There are quite a lot of Linux folks who are interested on the music making side though, so that side is actually very well and widely covered. But CCA is not falling into that area at all.

[asdf1000]

14 minutes ago, Miska said:

 

Most of Linux community probably couldn't care less, they are not audiophiles. Afterall, they are fine with Pulseaudio too!  They are probably perfectly fine with the CCA's analog output... If it gets cracked it is more likely for the video features and less likely for audio. People at large are more interested on video. There are still audio codecs that ffmpeg project didn't bother to reverse-engineer.

 

There are quite a lot of Linux folks who are interested on the music making side though, so that side is actually very well and widely covered. But CCA is not falling into that area at all.

 

Noted.

 

I guess we can make a feature request for shairport-sync in HQPe here.

 

It keeps all Apple users happy, as they can airplay from Spotify, Apple Music, Deezer etc, direct to HQPe without any new hardware. Limited to 16/44 for now but that's fine with those apps.

[Miska]

12 minutes ago, Em2016 said:

I guess we can make a feature request for shairport-sync in HQPe here.

 

I won't touch it with a mile long pole, but luckily there's nothing for me to do. You can configure shairport to output to ALSA loopback device and configure that as one input option to HQPE.

 

[gvl]

On 12/6/2018 at 2:11 PM, Miska said:

 

If there's 1 Hz difference in sampling rate it should take a bit over 12 hours of non-stop playback before that happens.

 

Ok, that is basically never unless the clocks are way off.

[gvl]

@Miska, speaking of PCM filters, is sinc-m the most technically precise of the bunch?

[Miska]

6 minutes ago, gvl said:

@Miska, speaking of PCM filters, is sinc-m the most technically precise of the bunch?

 

Well, that is actually not very straightforward thing to answer. It depends on which aspect once considers being most important for technical precision and what kind of source generated the content. IOW, what are properties of the source from technical perspective. Like if you assume a perfect source, or if you assume a real world ADC as a source for example.

 

[gvl]

1 hour ago, Miska said:

 

Well, that is actually not very straightforward thing to answer. It depends on which aspect once considers being most important for technical precision and what kind of source generated the content. IOW, what are properties of the source from technical perspective. Like if you assume a perfect source, or if you assume a real world ADC as a source for example.

 

 

For the lack of a perfect source, let's assume a real world ADC for practical reasons then?

[Miska]

10 minutes ago, gvl said:

For the lack of a perfect source, let's assume a real world ADC for practical reasons then?

 

I'd say it goes into category of poly-sinc-ext2, poly-sinc-xtr or sinc-M if you put more weight on frequency domain. Or poly-sinc-short if you want to weight time domain more. For example ext2 and xtr are very similar, but have different slope (transition band).

 

[gvl]

22 minutes ago, Miska said:

 

I'd say it goes into category of poly-sinc-ext2, poly-sinc-xtr or sinc-M if you put more weight on frequency domain. Or poly-sinc-short if you want to weight time domain more. For example ext2 and xtr are very similar, but have different slope (transition band).

 

 

Thank you. Can you please explain the differences between the poly-sinc and sinc filters? Also, is sinc-M a sharp linear phase filter?

[Miska]

3 minutes ago, gvl said:

Thank you. Can you please explain the differences between the poly-sinc and sinc filters? Also, is sinc-M a sharp linear phase filter?

 

They are processed in a different way. Yes, sinc-M is very sharp linear phase filter with over 240 dB stop-band attenuation.

 

[gvl]

6 minutes ago, Miska said:

 

They are processed in a different way.

 

But technically similar? My understanding is async processing allows to avoid compromises that have to be done in the poly-sinc ones. Is this close?

[Miska]

13 hours ago, gvl said:

But technically similar? My understanding is async processing allows to avoid compromises that have to be done in the poly-sinc ones. Is this close?

 

There's only one ASRC and it is now called ASRC. All others are synchronous. Processing itself is asynchronous and completely independent of DAC's clock, but synchronous to the sampling rate (mathematically, but not in relation to time). There are no compromises with synchronous converters as such. ASRCs have compromises because they need to be able to adjust the resampling ratio constantly on the fly. But the way the one ASRC is used in HQPlayer, it is not adjusting ratio on the fly.

[AudioXP]

On 11/24/2018 at 2:38 AM, shadowlight said:

Document updated to include options for updating the embedded package once a newer version is released.  I also added commands to update the OS packages if someone wants to update in the future.  I run the command once a month to make sure that I have the latest packages installed, especially security updates.

 

HQPlayer Embedded Install Guide v.0.7a.pdf

 

Thanks for maintaining this guide. I've followed it numerous times for doing a fresh install, using both Ubuntu and Debian, and also taking into account the instructions given earlier in this thread (e.g. sudo apt install -f to fix missing dependency errors following installation of hqplayerd).

However I always end up hqplayerd not announcing the UPnP renderer in my network. 

This is the output I get from sudo systemctl status hqplayerd.service:

 

● hqplayerd.service - HQPlayer Embedded daemon

   Loaded: loaded (/lib/systemd/system/hqplayerd.service; enabled; vendor preset: enabled)

   Active: active (running) since Mon 2018-12-10 18:28:16 CET; 1min 1s ago

Main PID: 1057 (hqplayerd)

   CGroup: /system.slice/hqplayerd.service

           └─1057 /usr/bin/hqplayerd

 

Dec 10 18:28:17 hercules hqplayerd[1057]:         additional mime type: audio/L16;rate=768000

Dec 10 18:28:17 hercules hqplayerd[1057]: Enable UPnP Renderer functionality for interface: auto

Dec 10 18:28:17 hercules hqplayerd[1057]: Adding interface 'eno1' for UPnP Renderer

Dec 10 18:28:17 hercules hqplayerd[1057]: property updated; volume: 0.50

Dec 10 18:28:17 hercules hqplayerd[1057]: rygel-media-device.vala:138: Failed to create device context: Failed to parse /usr/share/rygel/xml/MediaRenderer2.xml

Dec 10 18:28:17 hercules hqplayerd[1057]: clPlayerDaemon::OnNameLost() for 'org.mpris.MediaPlayer2.hqplayerd'

 

The log file looks fine, ends with:

 

2018/12/10 18:28:17 Enable UPnP Renderer functionality for interface: auto

2018/12/10 18:28:17 Adding interface 'eno1' for UPnP Renderer

 

The only workaround I've found, is to install Rygel (!), but this is not anymore supposed to be required...

 

Any ideas...? Thanks.

[shadowlight]

I am hoping @Miska will comment  on the problem but I have always installed rygel after the first time when it did not work.

[gvl]

@Miska, does the eval HQPE require a full system reboot after 30 minutes?

[Miska]

2 hours ago, AudioXP said:

Thanks for maintaining this guide. I've followed it numerous times for doing a fresh install, using both Ubuntu and Debian, and also taking into account the instructions given earlier in this thread (e.g. sudo apt install -f to fix missing dependency errors following installation of hqplayerd).

However I always end up hqplayerd not announcing the UPnP renderer in my network. 

This is the output I get from sudo systemctl status hqplayerd.service:

 

● hqplayerd.service - HQPlayer Embedded daemon

   Loaded: loaded (/lib/systemd/system/hqplayerd.service; enabled; vendor preset: enabled)

   Active: active (running) since Mon 2018-12-10 18:28:16 CET; 1min 1s ago

Main PID: 1057 (hqplayerd)

   CGroup: /system.slice/hqplayerd.service

           └─1057 /usr/bin/hqplayerd

 

Dec 10 18:28:17 hercules hqplayerd[1057]:         additional mime type: audio/L16;rate=768000

Dec 10 18:28:17 hercules hqplayerd[1057]: Enable UPnP Renderer functionality for interface: auto

Dec 10 18:28:17 hercules hqplayerd[1057]: Adding interface 'eno1' for UPnP Renderer

Dec 10 18:28:17 hercules hqplayerd[1057]: property updated; volume: 0.50

Dec 10 18:28:17 hercules hqplayerd[1057]: rygel-media-device.vala:138: Failed to create device context: Failed to parse /usr/share/rygel/xml/MediaRenderer2.xml

Dec 10 18:28:17 hercules hqplayerd[1057]: clPlayerDaemon::OnNameLost() for 'org.mpris.MediaPlayer2.hqplayerd'

 

The log file looks fine, ends with:

 

2018/12/10 18:28:17 Enable UPnP Renderer functionality for interface: auto

2018/12/10 18:28:17 Adding interface 'eno1' for UPnP Renderer

 

The only workaround I've found, is to install Rygel (!), but this is not anymore supposed to be required...

 

Any ideas...? Thanks.

 

On Ubuntu for example that MediaRenderer2.xml file is found in package "rygel", which will pull in tons of unnecessary stuff too, although only that single XML file ends up being used from it. But you don't need to run the "rygel" process at all...

 

[Miska]

55 minutes ago, gvl said:

@Miska, does the eval HQPE require a full system reboot after 30 minutes?

 

No, but the service needs to be restarted to continue...

 

[gvl]

52 minutes ago, Miska said:

 

No, but the service needs to be restarted to continue...

 

 

Ok, but merely pressing the play button on the main page won't be enough to continue? The reason I ask is that I can resume playback with just the play button and maybe re-selecting the input but it stops soon again, wasn't sure if this is due to the demo mode or some other underlying issue.

[Miska]

1 hour ago, gvl said:

Ok, but merely pressing the play button on the main page won't be enough to continue? The reason I ask is that I can resume playback with just the play button and maybe re-selecting the input but it stops soon again, wasn't sure if this is due to the demo mode or some other underlying issue.

 

If it works fine for 30 minutes after startup, then it is likely demo mode. After some playback time it goes silent too although you can still restart the playback.

[gvl]

I must say that sinc-m/ns5 at 8x rate sounds superb through a 24 bit Metrum DAC. I gave up on NOS long time ago and I've been using SoX via JRiver and Daphile prior and found I could not get satisfactory results above 4x oversampling with whatever SoX options were exposed in each player (JRiver has none), and I thought the DAC just couldn't keep up at higher rates but apparently not so as with HQPE at 352kHz it feels like the DAC finally performs at its full potential,  well, to my ears anyway. And this is listening to Spotify, not even lossless.

[gvl]

Afaik for native DSD support a particular DAC id must be added to the Linux audio stack. Is there support for Khadas Tone Board in HQPE already?

[Miska]

2 hours ago, gvl said:

Afaik for native DSD support a particular DAC id must be added to the Linux audio stack. Is there support for Khadas Tone Board in HQPE already?

 

Are you planning to use it through USB or plug (Generic) it on some small computer through I2S (VIMs)?

[gvl]

35 minutes ago, Miska said:

 

Are you planning to use it through USB or plug (Generic) it on some small computer through I2S (VIMs)?

 

I have just a generic board for now, so USB it is.

[Miska]

7 minutes ago, gvl said:

I have just a generic board for now, so USB it is.

 

Since it is based on XMOS, it may be using XMOS or Thesycon vendor ID. In which case with new enough kernel (4.18+), or alternatively one of my kernel builds or images it could work automatically without explicitly listing the product. Or if you can get someone to answer what USB VID (vendor ID) it has (or check it yourself), we would know...