HQPlayer Linux Desktop and HQplayer embedded

[Johnseye]

Is there a consensus on whether HQPlayer embedded provides better sound quality over HQPlayer desktop?

[Johnseye]

7 minutes ago, shadowlight said:

 

I have not personally compared the two but you can leverage the image provided by Miska to test it out in your own setup.  Just boot from usb flash drive.  My number one requirement was the ability to stream Tidal/Deezer/Qobuz or any other streaming service to UPnP renderer and right now that functionality is only supported under embedded.  If you have Roon and Tidal or your goal is to stream only your music you do not need embedded solution.

 

When you do the compare make sure that you are not dependent on Cuda, since the image provided by Miska does not support that.

 

Thanks for the info.  If I setup a comparison I'd prefer to keep it apples to apples and run them on the same drive.  In this case it would mean installing embedded HQP to an SSD.  No cuda in my rig.  It will upsample DSD512 fine without it.  I will be running Roon with Tidal to HQP.  Whether I use HQP on the server or install it as an NAA is to be determined.

 

Other than the streaming service direct to renderer functionality, are there any other benefits of the embedded over desktop?

[Johnseye]

7 minutes ago, shadowlight said:

The OS build for embedded is minimal so there are more resources available for the software.  Couple of other things that will come into play for you that you might want to keep in mind.  If you are currently running Windows based OS and you have already gone through the effort of stripping down / optomizing the OS the difference might not be night and day in resource usage between the two OS.

 

• Does your DAC support native DSD512 under Linux, if not you will need a Windows based NAA
• How comfortable are you with Linux?  If you are comfortable you can install both minimal Debian Stretch or Ubuntu Server Xenial 16.04 on the same SSD as your existing Windows.  If you are not that comfortable or concerned about losing your Windows setup if something went wrong during install, install it on a second SSD that is similar.

 

Edit: I am not sure if the input option is only available under embedded or if it is available under desktop version also.  I use the input option to forward input from Chromecast Audio to Mini-DSP USBStream toslink to usb converter so I can stream Deezer HiFi and Spotify.

 

My DAC does support DSD512 under Linux.  I've just installed Audiolinux and am comparing the SQ to my previous Windows build.  I am comfortable with Linux, no issue there.

 

Sound quality is my primary concern.  What makes it embedded?  Is it essentially Linux running HQPlayer and nothing else?

[Johnseye]

10 minutes ago, shadowlight said:

 

Embedded does not have any GUI, so no need for any X-Windows/Window manager related stuff running.  All configuration for HQPe is managed via web interface.  I run my system totally headless and if I need to make configuration change for the OS I just do that via ssh and commandline or edit files.  Hopefully, I am not confusing AudioLinux with something else but that is nice a turn key solution base on ArchLinux which allows you to try both desktop and embedded version under Linux on the same system.  I believe it still runs some kind of Window manager even if you are using it as embedded only solution.

 

With embedded you get the UPnP and input selection (Chromecast) with out losing any of the existing integration with Roon/Tidal provided it meets your sound quality requirement.

 

Thanks.  You're correct about Audiolinux.

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

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

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

[Johnseye]

3 hours ago, sig8 said:

I am just trying Audiolinux for the first time and have it installed on a PC. First time venturing out with Linux and have some questions.

 

1. How do I get the .xml registration file for this installation? 

2. What are my remote control option. I was using Geoffrey Armstrong's JRivertoHQPlayer when using a Win 10 set up. Any such thing with this set up? Is there anything like Remote Desktop here?

3. I am sure there are some Holo Spring DAC users here, do I need to install a driver for this DAC (I have a SU-1 between the computer and the DAC and connect to DAC with I2S).

 

I'm also running Audiolinux with the Holo Spring.  If you wouldn't mind, please let me know if you have any issues upsampling to PCM 384 or DSD512.  For some reason I'm having an issue in Linux where I didn't have one in Windows.

[Johnseye]

16 minutes ago, hifi25nl said:

In my Holo audio Spring both upsampling are working fine. Maybe the new xmos 208 usb board has a different code? 

You can send me the output of lsusb command in a terminal and I will check and eventually I will make a kernel patch.

 

I'll send it to you tonight Piero, and thank you.  I can't say enough about how good you are at responding and helping.

[Johnseye]

Jussi,

 

If I were to use Roon on a server to send music to HQPlayer as a NAA on NUC running Audiolinux, which I would load into RAM, would I install HQPlayer just like any other installation, or would I use a version linked by EM2016?

 

Thanks

[Johnseye]

I'm not using Embedded, only the regular Linux version.

 

By the way, you hit 11,000 posts.  Congrats.

[Johnseye]

2 minutes ago, Miska said:

 

OK, then it is probably not exposing similar problems. Maybe there's a tool on that distro to install HQPlayer. But hopefully someone else who has used it before can tell.

 

 

Piero distributes it with a script to install HQPlayer.  Is this all I need to do to run HQPlayer as an NAA in Linux?

 

systemctl --user start networkaudio
systemctl --user enable networkaudio

 

[Johnseye]

Jussi do you have any plans to allow for ramroot with either HQPlayer embedded or NAA? 

[Johnseye]

28 minutes ago, lmitche said:

John, both apps run from ramdisk based AL today no problem. What more do you need?

 

To run HQPlayer without any other overhead. 

 

19 minutes ago, Miska said:

 

Why? It is completely pointless. And in addition HQPlayer or NAA don't care what they run off, as long as the environment is proper. If they don't work, then the environment is broken in some way.

 

Relevant parts of HQPlayer and NAA stay in RAM without "ramroot". And irrelevant (unused) parts would be just wasting precious memory for no reason. Generally there are lot of files on rootfs that are only used during boot up phase and not touched after the system has reached running state. Keeping such things in RAM constantly doesn't make sense.

 

For example the bootable HQPlayer / NAA OS images I make are designed to work perfectly for their own respective use cases.

 

 

I'm order to eliminate the boot device and any noise generated by it. 

 

[Johnseye]

5 hours ago, Miska said:

 

It is in sleep state anyway when not being accessed...

 

If you are worried about noise, use microSD card as OS device, it has certainly less noise than RAM. If you want RAM-disk like behavior without having to host a lot of unnecessary data in RAM, use Optane on M.2 slot.

 

 

Actually the SSD, microSD or USB card will still generate noise.  USB can be removed.  We often run our devices in a high power mode, disabling sleep states, where the components do not sleep.

 

I do not believe a microSD card as OS is less noise than RAM.  In fact many of us have found that loading everything into RAM sounds significantly better.  The RAM is cheap and going to be in use regardless.  By loading the OS from USB into RAM, then removing the USB you are completely removing a power (SSD/USB/microSD) power source.  I have tested Optane and have found much better sound quality by loading everything into RAM vs using Optane.  We aren't talking about a lot of storage either.  This isn't to store the music files, only the software.

[Johnseye]

53 minutes ago, Miska said:

 

Well, you cannot fully do that on Linux and there's no point in doing it anyway. You just increase power consumption and noise.

 

I want to have everything that is not being used in a sleep state. Modern hardware can enter really low power states, being essentially off, but still ready to wake up when needed.

 

 

Of course it has, one of primary drivers of noise is power consumption. microSD consumes very little power and goes to sleep when it is not being accessed. It doesn't even need cooling, fast DDR4 RAM does. That's why you can use microSD nicely in mobile phones and digital cameras.

 

 

I take objective path and instead measure the DAC output noise...

 

 

I've heard different opinions about that... But software is loaded to RAM anyway when it is running, so the place where it stored doesn't make difference from that point of view.

 

Now my HQPlayer Embedded machines boot up in couple of seconds from M.2 and I'm happy. So it is just like turning on / off a traditional piece of hifi equipment.

 

 

And the storage for software doesn't matter anymore once the software is running. You don't need a second copy hanging around on RAM disk for that. But with RAM storage you will have issues with things like storing HQPlayer settings and music library data across reboots.

 

 

The difference is that music storage is accessed during playback while the software storage is not. By playing with the software storage you are playing with the wrong thing... I rather put more focus on the music storage.

 

 

But overall, this discussion shows exactly why I want to keep doing my HQPlayer OS images. I don't mind other people doing different way either. I just personally feel that I know what I'm doing after having been working on embedded systems for a long time.

 

My point is that if you load everything into RAM, the physical device, whether it be microSD, SSD or USB can be completely eliminated or removed.  I understand it can go into a sleep state, but gone is better than sleeping.  There's no doubt or question of influence if it isn't even there.

 

If you don't want to even include an option for ramroot in your products that's your decision.  Myself and others have found an audible benefit in doing so using your products while installed in Audiolinux.

[Johnseye]

50 minutes ago, shadowlight said:

@Johnseye have you thought about using PXE boot as a potential substitute for ramboot option?

 

I haven't tried it, but it's been discussed and tried by others.  I'm currently running HQPlayer Desktop and NAA that are installed with Audiolinux on a USB device.  I load that into RAM and remove the USB stick.  No drives are physically attached.  I used to have an SSD which I'd power separately from an LPS.  Others have used separately powered microSD cards.  We've found completely removing these devices to have a positive SQ impact, likely because of noise reduction.

[Johnseye]

Just now, Miska said:

 

If you don't physically pull it off, it doesn't make a difference. And I certainly don't want to go and physically remove hardware from devices every time I boot it up. That doesn't sound like zero configuration plug and play.

 

Physically pulling a USB stick out after it loads into RAM is unplug and play.  This isn't hard.

 

Just now, Miska said:

 

What do you mean by "option for ramroot"?

 

 

For example, when your NAA begins to load there could be a Yes/No option with a 5 second timer that asks if you want to ramroot or not.  Default to no.  If someone selects yes it loads to RAM.

[Johnseye]

1 hour ago, Miska said:

 

Physically pulling out microSD is harder, not to even mention impossibility of pulling out eMMC. And M.2 storage wouldn't like it.

 

Agreed unless you power these devices separately. Then you unplug the power. 

 

1 hour ago, Miska said:

 

Are you now talking about my bootable images? For NAA it is more of a possibility, for HQPlayer Embedded not. Reason is that NAA doesn't have much data that could be changed on rootfs while HQPlayer has.

 

I am only referring to your bootable images, nothing more. 

 

1 hour ago, Miska said:

 

How would you answer to that prompt? Of course I don't have any monitor or keyboard attached to my NAA's. Although one of the NAAs has two line alphanumeric LCD and four push buttons on front panel. Now the display just shows incoming audio format and other status information.

 

If you don't have a Y and N option then you can use a 1 or 2 option. 

 

1 hour ago, Miska said:

 

That 5 second timer would make booting up NAA longer, about as much extra as it now takes time to boot up from cold in first place.

 

How often do you reboot? What's 5 seconds in a boot process for this application? Make it a 3 second delay. I leave my server and NAA running so only reboot when making changes to something. 

 

1 hour ago, Miska said:

 

Well, it loads to RAM anyway...

 

 

But you can't remove or power off the drive that loaded it into RAM. 

 

[Johnseye]

6 minutes ago, shadowlight said:

How do you handle configuration changes that need to written back to disk if everything is running via ram boot and the physical media is disconnected?

 

If I want to make the change permanent, I reboot into the USB drive, make the change the boot back into RAM. You can make changes, upgrade packages in Ramroot but those obviously get lost when you shut down. 

[Johnseye]

2 hours ago, Miska said:

 

eMMC is typically soldered to the board (UpBoard and UpSquared for example). And M.2 gets it's power from the 4x PCIe bus which is typically not set up for hotplug anyway.

 

 

I want the NAA to work just like you would power up and down your amplifier or CD player. I turn them off when not needed.

 

But problem with prompts in first place is that NAA is not supposed to have any display or input device, apart from possible having some small front panel display to show incoming format.

 

Anyway, I made a RAM filesystem NAA image, it's now at the standard place, replaced the old HQPE+NAA combo image with name naa-3552-x64.7z

You can now pull off the storage after booting if you want. Side effect is that if you want to change name of NAA in persistent way or store ALSA settings in persistent way, you cannot. Takes somewhat longer to boot than standard image because it needs to load entire system to RAM. For the same reason I didn't include WiFi support either, because it also practically needs persistent configuration.

 

If you want to change those settings in persistent way, you can use the HQPlayer Embedded image which also contains NAA nowadays. It boots in normal way.

 

Thanks, that was a fast change!  I'll try it out and let you know how it goes.

 

2 hours ago, Miska said:

 

 

You sort of can, by letting it go to sleep mode. This is for example part of SATA and PCIe.

 

Sort of

[Johnseye]

17 hours ago, Miska said:

 

Anyway, I made a RAM filesystem NAA image, it's now at the standard place, replaced the old HQPE+NAA combo image with name naa-3552-x64.7z

You can now pull off the storage after booting if you want. Side effect is that if you want to change name of NAA in persistent way or store ALSA settings in persistent way, you cannot. Takes somewhat longer to boot than standard image because it needs to load entire system to RAM. For the same reason I didn't include WiFi support either, because it also practically needs persistent configuration.

 

 

I tested the NAA with ramroot.  It loads extremely fast.  I pulled out the USB and everything functioned as expected.  SQ is great at first listen.  Thank you very much Jussi.  Are there complexities in adding a similar capability to Embedded in one way shape or form?

 

[Johnseye]

Hey there Jussi @Miska, can you please explain the differences between poly-sinc-xtr, sinc-M and closed-form-M filters?

 

Thanks

[Johnseye]

On 3/16/2019 at 9:25 AM, Miska said:

 

I got PCM upsampling to 768k, and DSD up to DSD128 working on Squared (quad-core Pentium).

 

For NAA I think the basic UpBoard is better because it is smaller CPU and has needed things, but if the Squared has some features you'd like it goes fine too.

 

Now there's the newer Edge device too:

https://up-shop.org/home/258-up-squared-edge-system-powered-by-intel-x7-e3950-soc-8gb-ram-64gb-emmc.html

But I don't have one yet to test with...

 

LogicSupply also has wide range of suitable fanless devices.

 

If you don't care about nice case and would like to have a small board inside your own case, there are other options too.

 

 

On 3/16/2019 at 10:02 AM, lucser said:

@miska thank you for your kind support as usually. I always wonder how you succed to handle your work and provide this tremendous amount of support for us! 

For the naa I don’t care of nice case as it will be anyhow out of sight. 

Actually Now I use an old mid2010 27” iMac and for NAA I have  rpi3, cubox i4pro an an odroid c2. For usb out Rpi3 is not a good choice, the cubox uncertain future, odroid C2 quite good. I had also a plan to use some fifo board + I2S to HDMI to test the I2S input on my Holo Spring Dac but this is other story for DIY :).

Do you think up board will be an upgrade over my odroid c2 in terms of net or usb capabilities?

I plan to puchase a Nuc8 or to built a new PC within 1000x1500 usd to use it with HQPe and maybe to upgrade the NAA to a reasonable priced solution (no sotm or such) if necessary from my existing ones. I’ve read a lot of posts here but didn’t find a suitable setup yet ( MB and CPU) to be a bit future proof (512 dsd capabilities and processor gen).

On the net also i also want to make some changes. I was looking for a switch with SFP ports (1 or 2) . I have already 2 FMC as I use 2 NAA so I could go with a switch with 2 sfp ports -> 2 fmc ->1+1 ethernet to each NAA or 1FMC-> switch with 1SFP -> 1+1 ethernet to each NAA. I was looking to a Cisco c2960g-8tc (1sfp) or Netgear GS310TP (135usd on amazon) or Netgear Gs GS110TPv2(180usd) both with 2sfp or something similar if has any pros for use in an audio setup (fanless, low electrical noise etc). Any recommendations?

 

That Upboard is very similar to this NUC board, the NUC7i7DNBE, and is the same board many people in this forum have been talking about and using for the NAA with great success.

 

https://www.intel.com/content/www/us/en/products/boards-kits/nuc/boards/nuc7i7dnbe.html

 

Here's the associated kit.

https://www.intel.com/content/www/us/en/products/boards-kits/nuc/kits/nuc7i7dnke.html

 

[Johnseye]

On 12/2/2019 at 2:27 AM, elan120 said:

Can HQPlayer Embedded be purchased with hardware fingerprint provided in later time?  The intended server is being build, while the Cyber Monday discount be over before server is ready.

 

 

I never saw a cyber Monday discount. Is it still around?