HQPlayer Linux Desktop and HQplayer embedded

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

[bodiebill]

16 minutes ago, lmitche said:

In my experience, at a general level, this is the best practice topology for SQ.

 

Recently I replaced the last downstream fiber bit to my NAA endpoint with CAT6 because it clearly sounded better to my ears. Some others have confirmed this effect. But I guess it depends on the quality of the fiber-capable devices.

Setup now:

router => CAT8 => server / JCAT net card FEMTO bridged => Cisco 2960G switch => fiber => MikroTik 305 => CAT6 => NAA endpoint

(Apologies to Jussi, works well for me.)

[Miska]

1 hour ago, vortecjr said:

We have a solution that works perfectly fine with the server taking directly to the endpoint. However, I can’t speak for other solutions and certainly not for home brewed solutions. You mixing us all into a group is improper. 

 

There are lot of Rendu and sMS-200 users who don't have sonicTransporter for example.

 

1 hour ago, vortecjr said:

P.S. The opticalRendu does have a switch and it has two connections just as you said it should have and it is forwarding packets just as you said it should. The server is connected on one port externally and the Rendu is connected on the other port internally. FYI the opticalModule OEM board in the server is just an FMC.

 

That switch should be directly connected to other switches instead of other switches being behind another network interface of a leaf node. This way the switches can employ switching management protocols between each other and the structure is proper.

 

 

Let's say you configure Rendu to be UPnP Renderer instead of NAA and you have UPnP Media Server on a NAS at the regular network side. In order for Rendu to access content there, the server between would need to forward packets between these two entities for the streaming to work. This is inefficient compared to a real switch doing same work, bouncing through the OS software layer instead of hardware level packet forwarding. It works, but there's no benefit in doing such.

 

[asdf1000]

22 minutes ago, Miska said:

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?

 

LOL! Classic. They don't use Tidal because... of Jay-Z? 

[agillis]

On 4/27/2020 at 3:45 AM, Miska said:

I just say I'm sick and tired answering "HQPlayer cannot see my NAA" kind of questions that are precisely due to this kind of setup.

 

I have never had this question. The software switch in the sonicTransporter passes all packets so there are no issues with HQplayer at all.

 

Also customer with this setup are running HQPlayer on the server!! This gives them a direct like to the NAA player device with no switches in between. This works very well AND allows for complete optical isolation between the server and player. This results in amazing sound from your DAC.

 

Our servers and players are designed for HQPlayer and we do extensive testing to make sure they work really well.

[agillis]

On 4/26/2020 at 5:44 PM, BCRich said:

Since they both don’t go directly back to a switch there is no chance for a switch-loop issue. Correct?

That is correct!

[jabbr]

21 minutes ago, agillis said:

That is correct!

I have multiple parallel connections to switches, dating back to the days of link aggregation...

my NAS and servers each have copper management interfaces (builtin) and fiber NICs

 

multiple parallel connections to switches DO NOT cause switch loops unless you've done something really weird.

[jabbr]

3 hours ago, lmitche said:

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.

 

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. 

[luisma]

16 hours ago, jabbr said:

so I you can do it but I don’t recommend this to people who don’t have networking expertise. 

Have you been able to use the latest kernels on your multihomed machines with no issues? after 5.2.21 I can't, not 5.5 or anything like it

 

[Miska]

1 hour ago, agillis said:

I have never had this question. The software switch in the sonicTransporter passes all packets so there are no issues with HQplayer at all.

 

Bridge mode is not multi-homed configuration, since there is only single IP on the bridge interface and single network. Instead this bridge could be as well replaced with a real switch having multiple copper and optical interfaces. It just turns computer with multiple network interfaces into software based switch. In this bridged configuration one of the interfaces can be left unconnected and the other one used to connect to a real switch together with the NAA. In such case there is of course no packet forwarding taking place in the software switch.

 

However, many attempt to use multi-homed configurations where the two interfaces have a different IP and subnet. This is very tricky to get working right.

 

Neither of these two offer any technical benefit over the recommended way, but the former one generally works.

 

[jabbr]

1 hour ago, luisma said:

Have you been able to use the latest kernels on your multihomed machines with no issues? after 5.2.21 I can't, not 5.5 or anything like it

 

Certainly. Multihomed servers, for example, are more common than servers with a single network connection. Multihomed *can* mean multiple connections to a single network/subnet, this being easy to set up. e.g.

 

192.168.1.10/24 and

192.168.1.11/24.

 

There would be no kernel that wouldn't support it.

 

I use netplan to configure my machines

[jabbr]

5 hours ago, bodiebill said:

 

Recently I replaced the last downstream fiber bit to my NAA endpoint with CAT6 because it clearly sounded better to my ears. Some others have confirmed this effect. But I guess it depends on the quality of the fiber-capable devices.

Setup now:

router => CAT8 => server / JCAT net card FEMTO bridged => Cisco 2960G switch => fiber => MikroTik 305 => CAT6 => NAA endpoint

(Apologies to Jussi, works well for me.)

 

Really the use of fiber or not is a personal preference and of zero consideration to the issues being discussed. Both are perfectly capable ethernet protocols. There are excellent switches and NICs for both.

 

Fiber has the advantage of eliminating the possibility of common mode noise transmission. At 10Gbe, the low jitter rates are similar for both. Same for newer 25/40 Gbe over CAT8. At higher rates such as 100Gbe, there are direct attach copper cables for short distances. All of these demain extremely low jitter. The direct attach cables plug directly into QSFP28 ports.

 

In any case your choice.

[Miska]

Just to note that there is no clock delivery between HQPlayer and NAA. And as long as TCP level delivery jitter doesn't exceed that about +-400 ms the network jitters don't matter either.

 

[BCRich]

On 4/27/2020 at 4:38 AM, BCRich said:

Hi,

It is using... CPU – Intel i7 8559U (4.5 GHz).

I’ve discovered a couple of things since this post....

1. I believe that the Summus Server is running HQPe Version 4.12.2, so it Is quite a bit behind. I’ve been told they working on updates.

2. I noticed that I had my Kecces Power Supply set to 20V output instead of 19V, I’m sure that wasn’t helping.

 

I will try running HQPe tonight as see how it is is. I’ve been using Roon only to prevent any unnecessary stress on the system. I was planning on doing this until the update(s) start to roll out.

 

If I purchase a embedded license for the Summus, is it tied to the Summus or can it be moved to another embedded server either a Sonic Transporter or say a custom build? You can answer me in a PM if you like.

Thanks for all the help.

Mike

 

 

 

@Miska

 

Hi Jussi,

Getting back to my original issue and based on my answer to your question, once things are up to date with the Summus Server do think things might be a bit more stable with regards to the stress level the Summus is seeing with HQPe or plan on going with a second more robust device? If I do need to go with the later how would you organize things? Both devices are capable of Running Roon and HQPe, my thinking is use the Summus as my core and play to the second server with Euphony/embedded on that. Or the Summus could be the receiving device, in both cases the endpoint is my OpticalRendu.

[BCRich]

This is a screenshot of ....poly-sinc-mp-2S/DSD5EC/ DSD 128 to DSD 128 Native. You had quite a few updates dealing with stability since the version that is in play on the Summus.

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

[Miska]

9 hours ago, lmitche said:

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.

 

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.

 

Quote

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.

 

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.

 

[jabbr]

1 hour ago, lmitche said:

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

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

9 hours ago, lmitche said:

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.

 

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

 

Quote

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.

 

 @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!

[The Computer Audiophile]

9 minutes ago, jabbr said:

token ring (which died in the ?1980s)

My first job out of college was replacing a token ring network ........... in 1998! And, it was the worlds largest haircare company. Not some small mom & pop shop! They used it as long as they could. 

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

[Miska]

26 minutes ago, lmitche said:

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

 

Not necessarily, you can play straight through HQPlayer too. Not that one would want to, but it is possible. Doesn't change anything in the picture though. But why does that matter in this context?

 

NAA moves one part of HQPlayer to a separate device and puts network between.

 

28 minutes ago, lmitche said:

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.

 

Of course I have multiple servers and multiple endpoints. But can you explain in technical / objective terms why such software switched network would improve sound quality? It is not actually non-switched, it still goes through your software switch layer, doing switching between the bridge adapter and the physical one, just as it does for broadcast, DNS packets and such between the two physical network interfaces.

 

[The Computer Audiophile]

4 minutes ago, Miska said:

It is not actually non-switched, it still goes through your software switch layer, doing switching between the bridge adapter and the physical one, just as it does for broadcast, DNS packets and such between the two physical network interfaces.

 

This could actually increase CPU utilization and noise within the endpoint versus offloading those tasks to a purpose built switch. 

[jabbr]

41 minutes ago, lmitche said:

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.

 

Sorry, no, fact. You clearly haven't used a good fiber switch