HQPlayer OS image and rpi 4 question

I was wondering about trying @jussi_laako’s HQ Player OS image on a rpi 4 for some PCM upsamping. Do I need a specific rpi 4 version? I think there are 1gb, 2gb, 4gb and 8gb ram versions.

I also have a desktop and embedded license, would the embedded licence cover HQPlayer OS running on a rpi4? I am probably only going to be testing/experimenting so the trial licence might be fine also.

I would recommend at least 4 GB for HQPlayer Embedded.

Embedded license covers running HQPlayer Embedded on a single device. You can choose which device it is.

Thanks I have loaded it onto the Rpi and its playing. I wanted to SSH into the device but it doesnt seem to like the password, I reset on embedded straight away and can use the web interface. Is there something different in respect of SSH? Thanks.

There is no password on HQPlayer OS, just the user id = root

You need to connect the rpi to a monitor, then login as root
Create a user id with password
usareadd xxx
passwd xxx and follow messages
Now you can ssh using the new user id

1 Like

The SSHD default configuration doesn’t allow root to log in via ssh. It’s a security issue. That issue doesn’t bother me and you can login as root with a simple config change.
The security Karens will inform you I don’t have a clue of course and bad things might/will happen. To each their own, google will help you if interested in pursuing that further.

Or to keep the mavens happy, create a new user at the terminal to login with:
adduser my-new-user

This is pretty offensive actually. The root (super) user on the HQP image has no password. The Pi is a fairly powerful devices to be used by bad actors if compromised. Even security cameras have been used as the source of attacks from compromised networks and those are nowhere near as powerful as the Pi. While, normally, I’d agree that limiting the root login directly is a minor stepping stone in the grand scheme of things. But, in the case root has no password, it’s really the right thing to do and keep it that way. Additionally, when users hold the security attitude that those who work in and understand this space are “Karens” it actually forces us to make life miserable by further limiting access.

In summary: Take minimal steps to not let your s* get compromised so the rest of the world isn’t negatively impacted when it does.

Edit and getting back on topic.
Yes, monitor + keyboard. Login as root (no pasword). Then use the instructions @Stefano_Antonelli gave to create an account with password. Enjoy your ssh with that new account. :slight_smile:

I did this, once I found my mini hdmi cable. Thanks.

Since then, I have managed to listen on two different systems, both my desktop and main stereo. I did have to grab and check my three RPIs first, swapping a 4gb one into the main stereo position which had a 2gb model. I have just been listenting to some hi-res, 96/24 msuic streamed from qobuz. I am sticking to PCM rather than SDM, I have poly-sinc-gauss as a general filter, with LNS15, auto sample rate with a rate limit of 768000 and auto rate family enabled. I even managed to add in convolution filters. Listening for 20 mins or so, the pi was sitting around 50% load, and it was only slightly warm to the touch (its in a metal case which acts like a heatsink - there is no fan.

I have only really had one issue, and I am not sure why. I had set the DAC bits to 32 as I was reading the manual for my Topping D90 DAC. A few minutes later the music started spitting static, I have never heard the like. Luckily, it wasnt too loud, and I managed to turn it down. I switched the DAC bits back to 0 as default. I have not had another static outburst, it could be something else entirely that caused this mind you. I will be cautious for a while I think. I usually run DSD 256 on this main stereo, so I am trying PCM upscaled 768kHz to see if I can hear any difference.

I do have a filter query though, but of the Topping D90. My desktop DAC, a RME ADI-2 DAC FS will disable internal filters above 352.8k I think, but I am not sure about the Topping, I am still looking. I can’t see a manual way of turning the internal filters off.

You can’t log in as root via ssh without setting a password for root firstly. So chill out.


Depends on configuration.

But, yes.

… but if you create a new user id with password you can … yes you can !

You can log in using ssh via the newly created user. Agreed. Then su to root with no password by default. Agreed.
This now begs the question, HQPlayerEmbeded OS has no root password set by default and SSH has been available for the past few months. By allowing root to create a user who can login remotely via ssh and then that user by default can become super user by typing su, it could be a concern.

People seem to be upset by allowing root (with password) to remote in via ssh by a config change in sshd_config. If you are really, really, security conscious you want to immediately set a root password at the console first thing and then not allow ssh at all by creating a local user. I would guess most are not doing that and are simply creating a new user to login via ssh and then that user can become root easily, (no password set for root) and believe they are good.

I set a password at the console for root first thing.
Then allow root to log in via ssh via a config change in /etc/ssh/sshd_config:
PermitRootLogin yes

Pick your poison.


What a lesson !

Here’s a non-toxic solution for peace of mind and convenience.

Disable password and root access in the config and it’s good to go…

Point is that in order to gain remote root access to the device, you need to perform operations on local console. So out of the box, you cannot easily gain remote root access without having access to local physical console.

I consider creating a local user a better option, because some remote attacker would need to figure out both username and the password. If you allow root logins with password, the attacker would only need to figure out the password.

Set your username and password to 32 character random strings and the security should be already pretty OK.

For my internet accessible machines, I don’t allow password logins in first place. Just key logins.