Some thoughts on Cabling for HiFi:
MESH or Cable
With due respect to other contributors, Mesh is a poor solution, especially for audio.
Mesh nodes share wireless bandwidth across hops — each relay from one node to another degrades throughput and raises jitter. The weakest link caps performance.
Network cables give a dedicated, lossless path to every device at maximum achievable bandwidth.
Optical or Ethernet
Again with due respect to other contributors. Optical cable is indeed fast and EMI isolated, but it is not a brilliantly practical residential solution.
If one assumes at least ten cable runs, you need a switch with ten or more optical sockets. That is going to get you into HiFi component upgrade money. Where will your spend get the best sound upgrade?
Furthermore, most devices only have standard RJ45 sockets, so you are either looking at a powered signal converter (optical > ethernet) at each socket in your wall, or immediately before each device that has no SFP socket. Messy and clunky.
Ethernet wires for me please.
Speed
It makes little sense to put Cat5e into a new installation. Demand for bandwidth is only going to get higher. Cat6a is hardly the frontier but other contributors have made salient points about value for money, cable stiffness and a lack of standards.
Shielding
As a baseline, you should use S/FTP cable ie screened foiled twisted pairs.
This level of shielding means that individual pairs within the cable are protected from each other, and the whole cable is sheathed to protect it from received EMI from surrounding power cables, transformers and RF sources.
It does make the cable a little bigger and a little less flexible, but given that cables are invariably bunched together and typically follow paths already used for power cable conduits, this is a non-negotiable for me.
NB. Do not undo all your good work by using cheap unshielded patch cables (UTP) between your patch panel (where all your cables come together in your network room) and your switch / gateway, or between your wall socket and your device. Use end to end S/FTP cables.
Mitigating PoE Interference
You should consider whether you are going to use Power over Ethernet (PoE). This means that your ethernet cable also provides a power supply to downstream devices. PoE is spectacularly convenient - no separate power blocks for access points and local switches.
(NB optical cabling, cannot transmit power, so that is another reason I would be disinclined to use it for my in wall network spine.)
The downside of PoE is that it is itself a source of EMI that can affect both the signal within the cable, and that in other cables following the same pathway through the house - especially where all your cables come together as they approach your router.
The solution is a dedicated switch for your audio gear. Personally, I do not believe you need pay a premium for an ‘audiophile switch’ when you know what you want to achieve but YMMV.
The goal is to isolate your audio switch and any connected audio devices from PoE and cable related EMI. This is achieved by choosing a switch that has its own power supply and a couple of optical sockets.
- The use of its own power supply means that you do not need to use PoE for the cable connecting your audio switch to your main switch / gateway. You can therefore turn PoE off for the in-wall cable to your audio switch.
- Optical sockets allow you to use optical fibre cables from your audio switch to your streamer / music server. This approach isolates your sources devices from any transmission of EMI that makes it to the switch.
The only caveat to this is that optical isolation only works if your streamer / music server has an optical SFP socket.
In a pinch, one could use a signal converter just before a non-SFP equipped streamer, to convert the optical signal back to standard ethernet. However, such a converter will require a power supply and so could reintroduce the interference you have worked to remove. There are audiophile converters but this feels like an expensive bandaid rather than a real solution, again YMMV.
Grounding
Probably a bit much for this post but it has been mentioned, so…
S/FTP shielded cable needs to be grounded, but at one end only. The issue comes when one connects two devices, both of which are grounded. This creates the ground loop warned about above, introducing exactly the interference you’ve been working to eliminate.
A last thought because I don’t know when to shut up
In wall cables are a pain to fix if they break. They typically break at one end rather than in the middle. The cause is most often damage from unplugging / replugging / wiggling / pulling.
You want your in-wall wire to be remain undisturbed, protected behind your dry-wall and under your flooring. It is a false economy to have an in-wall cable hanging out of your wall and connected directly to a device. Instead:
- have your in-wall cables connect to the back of RJ45 sockets mounted securely into the wall or skirting board. Then connect your device to the socket with its own short cable. Unplug, wiggle, pull as often as you like. Most likely you will only ever need to replace the short cable or possibly the socket. No ripping out drywall required.
- have all your in-wall cables come together into a dedicated patch panel fixed to the wall or to a fixed rack. Run short cables from the patch panel to your main switch. You can then rearrange your rack as often as you like with minimal risk to the in-wall cabling.
This doesn’t mean that your in-wall cables will never fail, but it dramatically reduces the likelihood that they will.
Ugh... sorry... I really will shut up after this.
Do not let your contractor staple cabling to joists and frames. Make sure the cables are loosely threaded through generous holes and ideally conduit.
This discipline means that should an in-wall cable fail, you can attach a new cable to the device-end of the broken one, and then pull it all the way through your house back out at the router end. Tah dah! cable replaced with some sweat and a little swearing rather than structural damage. Staples, zip ties and small holes will prevent this fix.