HQPlayer Linux Desktop and HQplayer embedded

[jabbr]

3 hours ago, BCRich said:

For instance the i9 Sonic Transporter that has both Ethernet and Optical Connections, that would or would not pose a problem? The optical connection is a Sonore OpticalModule inside the server and meant to be connected to a OpticalRendu. I’m guessing you are talking about two network connections on the same device connected to a switch.

 

Not quite. Connect either one of the fiberoptic or copper ethernet connection from the Sonic Transporter to a switch which has an SFP port and also connect the opticalRendu to the same switch using the SFP port on the switch and the SFP port on the opticalRendu. 

 

The fiberoptic ethernet connection from the Sonic Transporter will also use an SFP port, so if your switch has 2 SFP ports you are all set.

[Account Closed]

2 minutes ago, jabbr said:

 

Not quite. Connect either one of the fiberoptic or copper ethernet connection to a switch which has an SFP port and also connect the opticalRendu to the same switch using the SFP port on the switch and the SFP port on the opticalRendu. 

That is not how Small Green Computer is advertising this. They are saying i9 can be connected directly to the oRendu. 

https://www.smallgreencomputer.com/collections/audio-server/products/sonictransporter-roon-server-hqplayer?variant=31106712502341

[BCRich]

I follow that but SGC recommends that the OpticalRendu be connected directly to the Sonic Transporter and that the Sonic Transporter be connected to the network through its Ethernet Port. My question to Jussi was that if it posed an issue with regards to a device having 2 Ethernet connections. Since they both don’t go directly back to a switch there is no chance for a switch-loop issue. Correct? I’m considering the i9 as possibly my solution to my HQPe problem. I would not be connecting the oRendu directly as the Summus and ST would be in another room.

[The Computer Audiophile]

This is from SGC

 

[BCRich]

7 minutes ago, bobflood said:

That is not how Small Green Computer is advertising this. They are saying i9 can be connected directly to the oRendu. 

https://www.smallgreencomputer.com/collections/audio-server/products/sonictransporter-roon-server-hqplayer?variant=31106712502341

You beat me to it Bob...🙂

[ericuco]

6 minutes ago, The Computer Audiophile said:

This is from SGC

 

Perhaps this discussion should be moved to one of the Sonore threads since this is their “recommendation” which runs contrary to what @Miska and others have recommended. Let them provide the technical support for this.

[BCRich]

My goal is to get the most out of HQPe while at the same time maintaining the sound quality of the Euphony Summus/Stylus or Summus/Roon scenario. The Summus is quite a bit behind with regards to HQPe updates and have been communicating with Arthur via email as I only have the Summus about a week, they are working on getting it updated. My Bryston BDA-3 is good up to DSD256 Native, not sure the Summus will be up to the task as far as the EC Modulators go, especially the ASDM7EC with any of the more demanding filters. Until the Summus is updated I really don’t know what direction I am going to head. Trying to get as much feedback as possible and I truly appreciate everyone’s input. This is really my only vice, granted it can be an expensive one. 🤑

[BCRich]

I may do a custom build so I can run Euphony on both.....

[AudioDoctor]

22 minutes ago, The Computer Audiophile said:

This is from SGC

 

 

I asked them about this as I am interested in the i9 SGC Optical, but I have not heard back. I thought it seemed odd.

[jabbr]

16 minutes ago, ericuco said:

Perhaps this discussion should be moved to one of the Sonore threads since this is their “recommendation” which runs contrary to what @Miska and others have recommended. Let them provide the technical support for this.

I couldn’t agree more. Certainly if they configure their OS distribution to properly handle multi-homed connections they they will be able to support what you would like to do with it. 
 

That said, “normal” users who want to set up an audio network in their home are advised to avoid multi homed connections. 

[Miska]

9 hours ago, BCRich said:

I follow that but SGC recommends that the OpticalRendu be connected directly to the Sonic Transporter and that the Sonic Transporter be connected to the network through its Ethernet Port. My question to Jussi was that if it posed an issue with regards to a device having 2 Ethernet connections. Since they both don’t go directly back to a switch there is no chance for a switch-loop issue. Correct? I’m considering the i9 as possibly my solution to my HQPe problem. I would not be connecting the oRendu directly as the Summus and ST would be in another room.

 

You could order i9 without optical connection, with just regular copper, and you are fine. In the room where you have oRendu, you would connect to optical port of a room specific switch.

 

In my diagram, each switch are in their respective rooms. And "switch1" is in the central patchbay in the machine room.

 

[Miska]

9 hours ago, The Computer Audiophile said:

This is from SGC

 

 

If you make this picture generic and sonicTransporter is what ever HQPlayer server and Rendu is what ever NAA, running any of the three OS, this kind of configuration is asking for trouble. 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. If the two network connections in the server are bridged, the server just becomes another software-based "Ethernet Switch".

 

Switches form a star-like structure on the network. They are core piece of equipment there. All networking hardware should connect to the switches, and if you have more than one room involved, you would likely have a switch in each room and one central switch where the room connections join. HQPlayer server and NAA connect to the network through a switch. If you have a NAA, HQPlayer server would likely be located somewhere else, for example a loud powerful rack mounted server in the basement.

 

When a switch is a managed one that can be configured, remember to check that 802.3x Ethernet Flow Control is enabled for all ports, otherwise especially devices like Rendu that cannot handle full gigabit speeds will have severe packet buffer overflows (can lead to stuttering). Even regular servers use this flow control a lot to avoid unnecessary packet losses.

 

You can also enable 802.3az Energy Efficient Ethernet / Green Ethernet that has couple of useful features. It can measure cable lengths and only use the needed amount of transmit power on the link, instead of blindly blasting at full power needed for the longest possible cable length. And it can make inactive links idle and power down unused ports.

 

Companies like HPE (Hewlett-Packard Enterprise) and Cisco for example make good switches. Less expensive smart switches from HPE

have relatively few simpler configuration options, while Cisco switches have a lot of configuration options. So that could be used as one decision factor when deciding between the two brands, depending on how much complexity one wants.

 

[Miska]

On 4/18/2020 at 4:00 PM, BCRich said:

Hi Jussi,

attached are some screen shots of what I am seeing using embedded, should I be concerned.

If I try going from FLAC 44.1 to DSD256 there are dropouts. This would be via Qobuz. My local files will be

DSD 64/128, hopefully I will be able to go to 256 using the EC Modulators.

If I purchase a Embedded License for the Summus and down the road decide to take HQP duties to a more powerful computer would that License be transferable?

Thanks.....Mike

 

Those temps are so high that you are likely running into thermal throttling already. But since going to DSD256 doubles the loads the CPU utilization would thus exceed 100%.

 

What CPU model does this have? Load pattern looks a bit strange for those settings.

 

 

[BCRich]

3 minutes ago, Miska said:

 

Those temps are so high that you are likely running into thermal throttling already. But since going to DSD256 doubles the loads the CPU utilization would thus exceed 100%.

 

What CPU model does this have? Load pattern looks a bit strange for those settings.

 

 

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

 

 

 

[The Computer Audiophile]

4 hours ago, Miska said:

 

If you make this picture generic and sonicTransporter is what ever HQPlayer server and Rendu is what ever NAA, running any of the three OS, this kind of configuration is asking for trouble. 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. If the two network connections in the server are bridged, the server just becomes another software-based "Ethernet Switch".

 

Switches form a star-like structure on the network. They are core piece of equipment there. All networking hardware should connect to the switches, and if you have more than one room involved, you would likely have a switch in each room and one central switch where the room connections join. HQPlayer server and NAA connect to the network through a switch. If you have a NAA, HQPlayer server would likely be located somewhere else, for example a loud powerful rack mounted server in the basement.

 

When a switch is a managed one that can be configured, remember to check that 802.3x Ethernet Flow Control is enabled for all ports, otherwise especially devices like Rendu that cannot handle full gigabit speeds will have severe packet buffer overflows (can lead to stuttering). Even regular servers use this flow control a lot to avoid unnecessary packet losses.

 

You can also enable 802.3az Energy Efficient Ethernet / Green Ethernet that has couple of useful features. It can measure cable lengths and only use the needed amount of transmit power on the link, instead of blindly blasting at full power needed for the longest possible cable length. And it can make inactive links idle and power down unused ports.

 

Companies like HPE (Hewlett-Packard Enterprise) and Cisco for example make good switches. Less expensive smart switches from HPE

have relatively few simpler configuration options, while Cisco switches have a lot of configuration options. So that could be used as one decision factor when deciding between the two brands, depending on how much complexity one wants.

 

Well said Jussi. 

 

I believe the whole direct connection thing, from PC to audio component bypassing a switch, started when some people reported it sounded better than going through a switch. Doesn't make sense to me, but I believe this is the origin of the configuration. 

 

I'll put a vote in for Ubiquiti UniFi network hardware. I have a full UniFi network and love it. 

[vortecjr]

13 hours ago, Miska said:

 

If you make this picture generic and sonicTransporter is what ever HQPlayer server and Rendu is what ever NAA, running any of the three OS, this kind of configuration is asking for trouble. 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. If the two network connections in the server are bridged, the server just becomes another software-based "Ethernet Switch".

 

Switches form a star-like structure on the network. They are core piece of equipment there. All networking hardware should connect to the switches, and if you have more than one room involved, you would likely have a switch in each room and one central switch where the room connections join. HQPlayer server and NAA connect to the network through a switch. If you have a NAA, HQPlayer server would likely be located somewhere else, for example a loud powerful rack mounted server in the basement.

 

When a switch is a managed one that can be configured, remember to check that 802.3x Ethernet Flow Control is enabled for all ports, otherwise especially devices like Rendu that cannot handle full gigabit speeds will have severe packet buffer overflows (can lead to stuttering). Even regular servers use this flow control a lot to avoid unnecessary packet losses.

 

You can also enable 802.3az Energy Efficient Ethernet / Green Ethernet that has couple of useful features. It can measure cable lengths and only use the needed amount of transmit power on the link, instead of blindly blasting at full power needed for the longest possible cable length. And it can make inactive links idle and power down unused ports.

 

Companies like HPE (Hewlett-Packard Enterprise) and Cisco for example make good switches. Less expensive smart switches from HPE

have relatively few simpler configuration options, while Cisco switches have a lot of configuration options. So that could be used as one decision factor when deciding between the two brands, depending on how much complexity one wants.

 

We need to get @gillis comments on what he is doing software wise on his server with respect to the dual network setup. On the hardware side the optical output to the opticalRendu is based on a opticalModule OEM board.

 

The Rendu is a switch and we already enable Ethernet Flow Control on it.

[Miska]

31 minutes ago, vortecjr said:

We need to get @gillis comments on what he is doing software wise on his server with respect to the dual network setup. On the hardware side the optical output to the opticalRendu is based on a opticalModule OEM board.

 

The Rendu is a switch and we already enable Ethernet Flow Control on it.

 

Simplified, you have a problem if more than one network interface has an IP address.

 

It doesn't matter if Rendu is a switch, switches should be connected to switches. But you shouldn't have a computer between two switches. Only exception to this rule is a firewall/router where you have explicit packet forwarding rules between the interfaces. And if you've ever looked into implementing multicast routing you know it's not among the simplest things to get right and working.

 

[vortecjr]

7 minutes ago, Miska said:

 

Simplified, you have a problem if more than one network interface has an IP address.

 

It doesn't matter if Rendu is a switch, switches should be connected to switches. But you shouldn't have a computer between two switches. Only exception to this rule is a firewall/router where you have explicit packet forwarding rules between the interfaces. And if you've ever looked into implementing multicast routing you know it's not among the simplest things to get right and working.

 

You said before that with the Rendu you need to set flow control on your switch and I’m just says no you don’t on the opticalRendu. The opticalRendu has a switch internally and it’s already set to flow control so that customers don’t need to set flow control in their computers or managed switches. Most customers do not have a clue how to set it on their computer or switches and this simplifies things. 

[jabbr]

3 hours ago, vortecjr said:

We need to get @gillis comments on what he is doing software wise on his server with respect to the dual network setup. On the hardware side the optical output to the opticalRendu is based on a opticalModule OEM board.

 

The Rendu is a switch and we already enable Ethernet Flow Control on it.

Well you can do it because Linux has router software — many of my machines are multihomed — typically I have a fast optical interface connected to a fast optical switch and also a slow management interface connected to a copper switch (or 1G RJ- 45 SFPs) *but* all my machines have a gateway ... so I you can do it but I don’t recommend this to people who don’t have networking expertise. 
 

That said so since you are set up to handle end user questions, your choice  

 

There is ZERO sonic benefit to doing it this way in my experience with a large number of very high quality network interfaces. 

[Miska]

3 hours ago, vortecjr said:

You said before that with the Rendu you need to set flow control on your switch and I’m just says no you don’t on the opticalRendu. The opticalRendu has a switch internally and it’s already set to flow control so that customers don’t need to set flow control in their computers or managed switches.

 

Then the server should be connected only to that switch and then everything else in the network should be connected to it too, and for that it should have more than one port so that internet access and everything else works through it too.

 

Otherwise it is pretending to be network without actually being a real network.

 

Problem is any normal computer (Windows, Linux, macOS) having more than one network interface active.

 

Quote

The opticalRendu has a switch internally and it’s already set to flow control so that customers don’t need to set flow control in their computers or managed switches. Most customers do not have a clue how to set it on their computer or switches and this simplifies things.

 

Flow control becomes enabled through automatic negotiation unless switch rejects it. If people have a managed switch, they need to manage it too. Such devices are not intended to be plug-and-play out of the box.

 

All my switches are managed and all computers connected to those switches have got flow control enabled automatically once it is enabled in the switch so that the feature gets negotiated.

 

[vortecjr]

19 minutes ago, Miska said:

 

Then the server should be connected only to that switch and then everything else in the network should be connected to it too, and for that it should have more than one port so that internet access and everything else works through it too.

 

Otherwise it is pretending to be network without actually being a real network.

 

Problem is any normal computer (Windows, Linux, macOS) having more than one network interface active.

 

Flow control becomes enabled through automatic negotiation unless switch rejects it. If people have a managed switch, they need to manage it too. Such devices are not intended to be plug-and-play out of the box.

 

All my switches are managed and all computers connected to those switches have got flow control enabled automatically once it is enabled in the switch so that the feature gets negotiated.

 

You don’t get to decide what our product should do and what features they should have anymore than I get to decide what you should include in your software.

 

Its fine and dandy to tell people to enable flow control on a complex switch and a complete windows OS, but when they don’t not have a clue what to do you can’t get sick and tired of answering questions...just saying. 

[Miska]

32 minutes ago, vortecjr said:

You don’t get to decide what our product should do and what features they should have anymore than I get to decide what you should include in your software.

 

Its fine and dandy to tell people to enable flow control on a complex switch and a complete windows OS, but when they don’t not have a clue what to do you can’t get sick and tired of answering questions...just saying. 

 

I'm trying to give guidance to avoid cases that end up with non-functional NAA (or alternatively for example non-functional IPP network printing) because of a second network interface and used direct connection to Rendu or any other NAA.

 

I'm not using such direct connection anywhere, and I repeatedly strongly advice against doing such. I get at least one email per day telling "HQPlayer cannot see my NAA" and almost invariably reason is multi-homed HQPlayer host. It is much better off to avoid this situation in first place, rather than afterwards having to remove the extra network interfaces that have already costed time and money.

 

P.S. It is not a switch really if it has only one port... Job of a switch is to forward packets between multiple ports.

 

[vortecjr]

10 hours ago, Miska said:

 

I'm trying to give guidance to avoid cases that end up with non-functional NAA (or alternatively for example non-functional IPP network printing) because of a second network interface and used direct connection to Rendu or any other NAA.

 

I'm not using such direct connection anywhere, and I repeatedly strongly advice against doing such. I get at least one email per day telling "HQPlayer cannot see my NAA" and almost invariably reason is multi-homed HQPlayer host. It is much better off to avoid this situation in first place, rather than afterwards having to remove the extra network interfaces that have already costed time and money.

 

P.S. It is not a switch really if it has only one port... Job of a switch is to forward packets between multiple ports.

 

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. 

 

We need the people in the silly thread to providing support for the silly things they come up with. You and I can’t go into the silly thread and complain because it’s not allowed...they are just having fun after all.

 

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.  

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

 

 

 

[Miska]

4 minutes ago, lmitche said:

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

 

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

 

5 minutes ago, lmitche said:

Adding a switch between endpoint and server introduces another power supply and latency that is unnecessary.

 

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.

 

6 minutes ago, lmitche said:

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

 

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.

 

9 minutes ago, lmitche said:

SQ is breathtaking.

 

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?