HQPlayer Linux Desktop and HQplayer embedded

[gvl]

7 hours ago, Miska said:

 

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

 

 

Here it is.

[Miska]

3 hours ago, gvl said:

 

Here it is.

 

Yes, that's XMOS' VID, so it should already work with my kernel builds and images.  (and Linux kernels >= 4.18)

 

[gvl]

8 hours ago, Miska said:

 

Yes, that's XMOS' VID, so it should already work with my kernel builds and images.  (and Linux kernels >= 4.18)

 

 

Great, thanks for the confirmation!

[simonklp]

Hi @Miska, after upgrading HQPE to version 4.7.0, I have found two issues as follows: -

1) I have noticed that you have added the CUDA offload status on the front page. But does “R” stand for offload resampler enabled?

2) I have found that all the Chinese characters of the albums and soundtracks have been changed to unrecognised codes. However, this was not the case before the upgrade. Could you please kindly fix this problem?

 

Thanks.

[Miska]

3 hours ago, simonklp said:

1) I have noticed that you have added the CUDA offload status on the front page. But does “R” stand for offload resampler enabled?

 

Yes, "R" for resampler and "C" for convolution.

 

3 hours ago, simonklp said:

2) I have found that all the Chinese characters of the albums and soundtracks have been changed to unrecognised codes. However, this was not the case before the upgrade. Could you please kindly fix this problem?

 

I have no idea why that could have changed, there are no changes to anything metadata or library related.

 

Sometimes if browser chooses to use a different font such may happen if the font doesn't include Chinese character set.

 

[simonklp]

45 minutes ago, Miska said:

 

Yes, "R" for resampler and "C" for convolution.

 

 

I have no idea why that could have changed, there are no changes to anything metadata or library related.

 

Sometimes if browser chooses to use a different font such may happen if the font doesn't include Chinese character set.

 

 

Hi @Miska, thank you for your advice. I might previously have done something wrong on the browser and etc. Now, it seems to have resumed normal. Thank you again for your reply anyway.

[gvl]

@Miska, is Santa working with you on holiday pricing? ?

[arglebargle]

@Miska et al,

 

I find with 4.7 that when Roon playback concludes naturally at the end of an album or playlist, the HQPlayer process continues to use CPU% at the same level as the previously played material. The log shows: 

  2018/12/15 11:41:07 End of track
& 2018/12/15 11:41:07 Next
  2018/12/15 11:41:07 Idle request

Instead of the following normal message when explicitly pausing / stopping playback in Roon

& 2018/12/15 10:46:03 Pause
& 2018/12/15 10:46:08 Stop...
- 2018/12/15 10:46:08 Network engine stopping...
- 2018/12/15 10:46:08 Network engine stopped
- 2018/12/15 10:46:08 Playback engine stopped
& 2018/12/15 10:46:08 ...stopped

Explicitly stopping through the web UI will then bring HQPlayer to a proper halt and there are no issues with initiating further  playback. Has anyone else observed this behaviour? cheers

[Miska]

1 hour ago, arglebargle said:

I find with 4.7 that when Roon playback concludes naturally at the end of an album or playlist, the HQPlayer process continues to use CPU% at the same level as the previously played material.

 

This is normal and works as intended. It should stop after about 10 seconds of idling if there are no further playback requests.

 

Because stopping an starting again is expensive operation, HQPlayer keeps things running for a while after it has finished currently playing things in case there are further playback requests. This makes transitioning to something else quite a lot faster.

 

[arglebargle]

How long is it meant to keep running? After Roon playback ends with an idle request, HQPlayer continues to use the same CPU% as required by playback until explicitly stopped with the Embedded web UI. It's not coming to a full stop after 5 minutes. Yesterday it was in this state for 5-6 hours until I noticed. But if not reproducible /  nobody else is experiencing such then maybe something with my configuration. 

[asdf1000]

25 minutes ago, arglebargle said:

How long is it meant to keep running? After Roon playback ends with an idle request, HQPlayer continues to use the same CPU% as required by playback until explicitly stopped with the Embedded web UI. It's not coming to a full stop after 5 minutes. Yesterday it was in this state for 5-6 hours until I noticed. But if not reproducible /  nobody else is experiencing such then maybe something with my configuration. 

 

Interesting. I just noticed the same for the first time. This is 5 minutes after Roon playlist naturally finished @Miska

 

[arglebargle]

@Em2016 Thanks for looking into it. When a track finishes playing naturally via Roon it seems to be getting stuck on idle. 

[asdf1000]

1 minute ago, arglebargle said:

@Em2016 Thanks for looking into it. When a track finishes playing naturally via Roon it seems to be getting stuck on idle. 

 

Yes. Things work as they should when I hit pause in Roon (CPU drops as it should).

 

So like you said, it's the natural finishing when there's nothing left to play, where CPU stays very high.

 

[Miska]

I found the problem (didn't exit idle state) and fixed it for next release. Until that side effect is higher CPU consumption in such cases, but faster restarts...

[shadowlight]

Updated the guide to include information on how to assign static IP address under Ubuntu Bionic and changed the web interface username and password to store the information under system.

 

 

HQPlayer Embedded Install Guide v.0.7b.pdf

[gvl]

Is wifi support in the pre-configured image something that's planned for a future release?

[Miska]

1 hour ago, gvl said:

Is wifi support in the pre-configured image something that's planned for a future release?

 

It is there already... But it needs some manual work to set up SSID and passphrase.

 

[gvl]

4 hours ago, Miska said:

 

It is there already... But it needs some manual work to set up SSID and passphrase.

 

 

Ah, nice, I missed that. Thanks. 

[gvl]

@Miska, another question. A couple of pages back you said that a HQPE box can act as a UAC device so another host can see it as a DAC, or at least I think that is what you said. Can you please describe the steps to make it work? Does the HQPE present itself as a UAC 1 or 2 device for <=96kHz sampling, and if it is the latter is there a way to make it work with Windows 7?

[Miska]

3 hours ago, gvl said:

@Miska, another question. A couple of pages back you said that a HQPE box can act as a UAC device so another host can see it as a DAC, or at least I think that is what you said. Can you please describe the steps to make it work? Does the HQPE present itself as a UAC 1 or 2 device for <=96kHz sampling, and if it is the latter is there a way to make it work with Windows 7?

 

It is UAC2 device, and you need hardware that supports USB Device Mode for running HQPE. Functionality itself is enabled on my bootable image, but it goes into experimental features category. With Windows 7 you would need to get a driver somewhere. I think the current driver in Windows 10 is a bit too broken to work either.

 

[gvl]

1 hour ago, Miska said:

 

It is UAC2 device, and you need hardware that supports USB Device Mode for running HQPE. Functionality itself is enabled on my bootable image, but it goes into experimental features category. With Windows 7 you would need to get a driver somewhere. I think the current driver in Windows 10 is a bit too broken to work either.

 

 

I see, do you have an example of such hardware? 

[Miska]

1 hour ago, gvl said:

I see, do you have an example of such hardware? 

 

Currently the only really functional one I have tested is UpBoard, also available as built passive cooled device:

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

 

UpSquared is supposed to work too, but it's BIOS is a bit flaky in that respect. I haven't got time to check yet if USB mode switch patches finally have landed in 4.19 that would make many things easier and possibly allow this on wider range of hardware through USB Type-C.

 

Note that limitation of the current Linux driver is that it can expose only single sample rate at a time.

 

[gvl]

Cool, I don't see anything specific mentioned in the specs though. So basically BIOS allows to change between host/device modes for USB ports? Would it be you who'd need to provide a Windows driver if it were an official HQPE feature or the hardware vendor? 

[Miska]

1 hour ago, gvl said:

Cool, I don't see anything specific mentioned in the specs though. So basically BIOS allows to change between host/device modes for USB ports? Would it be you who'd need to provide a Windows driver if it were an official HQPE feature or the hardware vendor? 

 

It needs some amount BIOS support and of course support from the hardware. Most PC hardware doesn't have device capable ports. Nowadays operating systems and most devices come with UAC2 compliant driver, so there's not really need for third party driver for this kind of use case. Hardware vendor could still license one from Thesycon for example.

 

[gvl]

In case of more than one network interface, will the UPnP renderer work on all of them? I don't have a wired network connection at the location where my main system is, I have a laptop with JRiver and WiFi and would prefer not to send audio traffic from JRiver to HQPE over WiFi. I could just wire the laptop to the HQPE box with an Ethernet cable (crossover if need to be...) and set up static IPs, at the same time it would be nice to also leave wi-fi working so I don't have to get up from the couch to change HQPE settings. Will this work? Is there a way to configure UPnP renderer settings per network interface? For example, I'd likely prefer to have different renderer names per NIC, along the lines of "HQPE-wired" and "HQPE-wifi", with the former only visible to the laptop/JRiver connected directly to the HQPE box, and the latter to all WiFi clients.

 

What about the admin web interface, will it work over all network interfaces?