HQPlayer Linux Desktop and HQplayer embedded

[lmitche]

11 minutes ago, Em2016 said:

And one more question:

 

I only see a 32-bit version of Ubuntu 16.04 for Intel CPU's here: 

http://releases.ubuntu.com/16.04/

 

I have an Intel i7-7700HQ, so is the 32-bit version fine to install HQP Embedded? I guess it's my only option because the 64-bit version is AMD right?

 

The AMD 64 bit version will work fine on an Intel processor.  Intel used AMDs 64 bit scheme when adopting 64 bits, rightly called AMD64 as AMD invented it.

[lmitche]

7 hours ago, Johnseye said:

 

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

 

Yep

[lmitche]

7 hours ago, hifi25nl said:

The only problem is that license is not recognized.

That makes sense. Is there a symbol that can be used to point to a license key on nonvolatile media?

[lmitche]

53 minutes ago, Johnseye said:

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

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

[lmitche]

12 minutes ago, Jud said:

 

I would. 🙂

Me too.

[lmitche]

On 4/26/2020 at 5:45 PM, The Computer Audiophile said:

This is from SGC

 

In my experience, at a general level, this is the best practice topology for SQ. It is simply a low power endpoint directly connected via a usb connection to a dac with a dedicated  fiber connection to a server. On the server either a wifi, copper or optical NIC to the router works. The quality of the power supply on the endpoint is critical to SQ. There are both ethernet and usb versions of this topology available with lots of options on the theme.

 

Some examples (not exhaustive): Server -> Endpoint

 

SGC i9 ->opticalRendu

Generic Intel or AMD server -> Generic Intel or AMD endpoint both with fiber NICs

Taiko Audio Extreme -> Monoprice Fiber Optic SlimRun USB 3.0

Generic Intel or AMD server -> Adnaco USB 3.0

 

Adding a switch between endpoint and server introduces another power supply and latency that is unnecessary. FMCs can introduce similar issues, so a single board endpoint with a sfp cage is best.

 

My Roon server runs at 99.75% idle during Qobuz playback with bridged NICs, so the switching overhead is negligible. SQ is breathtaking.

 

 

 

[lmitche]

1 minute ago, Miska said:

 

It doesn't affect sound quality as long as you don't get drop-outs.

 

 

And a switch adds two more isolation transformers on the path which improves isolation. Latency doesn't matter as long as it stays below about 900 ms. Packet jitter can be tolerated to about +-400 ms without any effect on the output.

 

I have typically three switches on the way from HQPlayer server to the NAA endpoint, since these are in different rooms. So there's a central patch bay switch (by Cisco) and two room specific switches (by HPE).

 

Most of the time you could replace the central patch bay switch with VPN and whole internet and likely it work fine between for example between Europe and US.

 

 

Software switching adds much more latency than a hardware switch. So you are not reducing latency but instead adding extra latency by using a software switch.

 

 

Yes, in my setup too.

 

 

P.S. For the same reason, why are you guys not demanding direct connection to Tidal's servers (that are IIRC actually Cloudflare's CDN)? How much would that improve Tidal SQ?

 

We are going to have to agree to disagree on these points

 

This is no surprise as we have been here before. 😁

[lmitche]

10 hours ago, jabbr said:

 

This is most certainly NOT "best practice" !!! That said your experience may be limited to consumer grade switches. Pro grade switches and NICs have extraordinarily low levels of noise.

 

What types of network equipment have you based your opinions on? Have you thoroughly tested this before arriving at your conclusions. I have tested  against a very broad spectrum of pro-grade equipment. 

Jabbr,

 

Why use a switch between a server and endpoint machine?

 

For music playback the stream running into the server app is different then the stream heading to the endpoint. This is where your Tidal argument falls apart. There is more than network transport at work here. Server apps take packets in from one bitstream,  network or disk, transform the bits, and next send the work product out the other pipe.  For music playback there is no "true" switching involved as no input stream survives the process. Bridging is just used as a convenience to setup two independent and dedicated physical circuits between two machines. Virtual circuit follows physical circuit here by design.

 

The one exception to this is in the case the endpoint is running an os, where one might run SSL for example to login and manage the endpoint software. Nevertheless for music playback there is no switching involved.

 

Indeed with the two usb solutions described above there are two different protocols stacks at work. Clearly there is no need for a switch as there are no packets arriving at the server nic that are ever forwarded to the endpoint. Instead the server app "transforms" packets into something else that is later forwarded to the usb endpoint for delivery to the dac.

 

In OSI terms the input and output streams have two different presentation (level 7) layers so there is nothing to be switched or routed.

[lmitche]

8 hours ago, lmitche said:

Jabbr,

 

Why use a switch between a server and endpoint machine?

 

For music playback the stream running into the server app is different then the stream heading to the endpoint. This is where your Tidal argument falls apart. There is more than network transport at work here. Server apps take packets in from one bitstream,  network or disk, transform the bits, and next send the work product out the other pipe.  For music playback there is no "true" switching involved as no input stream survives the process. Bridging is just used as a convenience to setup two independent and dedicated physical circuits between two machines. Virtual circuit follows physical circuit here by design.

 

The one exception to this is in the case the endpoint is running an os, where one might run SSL for example to login and manage the endpoint software. Nevertheless for music playback there is no switching involved.

 

Indeed with the two usb solutions described above there are two different protocols stacks at work. Clearly there is no need for a switch as there are no packets arriving at the server nic that are ever forwarded to the endpoint. Instead the server app "transforms" packets into something else that is later forwarded to the usb endpoint for delivery to the dac.

 

In OSI terms the input and output streams have two different presentation (level 7) layers so there is nothing to be switched or routed.

Sorry, I should have said level 6 of the OSI model.

[lmitche]

1 hour ago, Miska said:

 

Why do you think it is different? The two pipes are very similar.

 

NAA has a large asynchronous RAM buffer. As long as the buffer doesn't run completely empty, the traffic pattern at the network side doesn't matter. If it runs empty, you have silent gap in the music.

 

 

Usually you would have server and endpoint in different rooms. And only one cable going from each room to the central patch bay. Switch in each room distributes internet access and access to other rooms to various networked devices in that room. And switch in the central patch bay distributes traffic between rooms and the internet.

 

This is for example how I have have things. Also in my listening room I have three servers and couple of end points. Having a switch makes it convenient to allow any server in the house reach any endpoint in the house same way. And also access content through SMB share elsewhere in the house.

 

Jussi,

 

Yes the streams are close but different and we know a switch does not change packet contents, instead it sends an exact copy of the input to the appropriate output port.

 

Your server application and others like roon or minimserver change the data contents, which was my point.

 

And yes of course, if you have one server and multiple endpoints you need a switch between them. But for best SQ non-switched fiber with a 1 to 1 ratio between server and endpoint wins.

[lmitche]

1 hour ago, jabbr said:

This is getting theoretical and a full discussion of network theory and practice goes way outside the topic of this thread.

 

I think you are mistaking me for @Miska here 😊

 

I must say that the HQPlayer software and HQPlayer/NAA model is one I find genius, and have set up my home audio system around. The SQ is absolutely fantastic. So I defer to, and learn from, his best practice  

 

Why switch? Switches are ASICs in a box that contain a MAC table and switch frames entering a port to the outgoing port connected to the destination MAC address. That's how Ethernet works: hub and spoke model. There are other models e.g. token ring (which died in the ?1980s) as well as mesh e.g. infiniband but thats waaaaaay outside of home networks... even infiniband has "blended" with Ethernet for the most part. See both Mellanox & Cray

 

 

 @Miska  knows how the packets travel in the system he designed and implemented. Computers are rather complex these days and contain a number of internal networks e.g. between cores, between memory, between PCIe devices including CUDA coprocessors. e.g. https://arxiv.org/pdf/2002.02563.pdf Once a network connection is established, the server MAC address sends a frame to the destination MAC address. A switch does that in hardware (ASIC). In my own system, I have perhaps 10 NAA devices -- at any point in time a number of them are unplugged -- and I can direct HQPlayer embedded to send music to the endpoint in the room I happen to be in ... so yes best practice is most certainly to use a switch!

LOl, my OSI point is hardly a full discussion of network theory. It is a simple point for those that understand the model.

 

Also please see my response to Jussi above.

[lmitche]

2 minutes ago, The Computer Audiophile said:

Hi Guys -I know I just piled on to the off topic discussion, but let's try to keep this one geared to HQPlayer. A different discussion about switching and sound quality would be good, just not in this thread. 

Your right, I'm done anyway. No one is listening.

[lmitche]

25 minutes ago, The Computer Audiophile said:

An unnecessary shot Larry. 

Your right, I should have said no one wants to listen.

 

I hear you.

[lmitche]

3 hours ago, hifi25nl said:

I see that last version of HQPlayer embedded (focal) has rocm libraries as dependency.

Could you make this optional and allow HQPlayer starting without installing these libraries?

Jussi,

 

Implementing this suggestion is helpful as in my case the rocm libraries take a ton of scarce Optane boot drive real estate.

 

Many thanks for the consideration.

 

Larry

[lmitche]

On 1/27/2021 at 3:31 AM, Miska said:

You can likely install the Debian Buster package

That worked, many thanks.

[lmitche]

32 minutes ago, Miska said:

 

No, you need to manually add it yourself, because it is experimental feature which may not work or may crash.

 

And of course it doesn't do anything if there's no suitable AMD GPU on the system.

 

It works essentially the same on AMD graphics cards as CUDA on Nvidia cards.

 

 

No, it is not related, I don't have the 6800 XT yet, I have it on order, but nobody has it in stock yet. I'm not using any ROCm support.

 

And GPUs cannot help with modulators.

 

 

So you are running regular build without ROCm enabled. If you don't have AMD graphics card, there's no ROCm in play at all. So you are using the build optimized primarily for Intel CPUs.

 

You'd get better performance on AMD CPU system by using the AMD optimized build that doesn't have ROCm support.

 

Jussi,

 

Just to be clear:

 

Are you saying there are four different builds of Hqplayer embedded?

 

1) CPU : AMD :GPU: AMD

2) CPU : AMD :GPU: Nvidia

3) CPU : Intel :GPU: AMD

4) CPU : Intel :GPU: Nvidia

 

 

[lmitche]

3 hours ago, Miska said:

 

No...

 

1. Regular Ubuntu build with support for Nvidia and AMD GPUs (Intel specific optimizations)
2. Ubuntu build optimized for latest AMD CPUs
3. HQPlayer OS build for x64
4. HQPlayer OS build for RPi4
5. Debian Buster build for x64
6. Debian Buster build for arm64
7. Fedora build for x64

 

OK thanks, got it!

[lmitche]

5 hours ago, guiltyboxswapper said:

That DSP cache really works for poly-sinc-xtr-mp (DSD512 rates)- on a ryzen 3900x (at 3.8ghz) it also looks like 30%+ reduction in CPU usage.  Nice work indeed.

I missed it. What DSP cache?