Ok. No switches?
But you also donāt have a 500 system to claim your truth is everyoneās truth. The higher up you go the more cables will affect the total IME.
You could also say āthere are many companies doing cables and cables only that have done so for xx yearsā.
If their cables didnāt change anything Iām sure their business model would be pretty challenging, right?
It was actually on a Linn system, although I cannot recall which one. The only thing that connects my Roon server to my DAC is a USB cable, so my system is Isolated from any network noise. My Roon server is a standalone Windows 10 machine, debloated, and just has Roon running on it.
It is often said that āyour mileage may varyā, which means you hear what you hear but on a very resolving system I can promise you ethernet cables make as much difference as any interconnects, speaker cables or power cables. In fact I would say that in a good streaming system they can make a monumental difference.
Well, I have more than enough experience with the cables of all types, thank you. Nobody can produce everything, there were times when Naim believed there was no need in Super Lumina, right? Linn and Rega cannot be a reference, theyāre very entry-level in terms of cables (though I like Rega for example, nothing personal here).
Just be mindful in the professional audio world as opposed to consumer hifi world this is a well trodden path with established audio industry protocols such as Dante and Milan/IEEE 1722.1 amongst the many - which are used to create much of what you hear these days anyway.
It doesnāt require any mystical artisan alchemy, those that need the right quality and applications buy the right established and usually standardised tools 
But this is primarily for synchronous bus streams for mixing desks and multi track recording etcā¦ honestly the world we are with home hifi streaming audio is really elementary compared to thisā¦ i really think much of this is a degree of hoodwinking (as evidenced my much of the advertising) in the consumer hifi world for well heeled enthusiasts with perhaps more money than understanding. No offence to anyone that has bought into this of course
I myself, perhaps motivated because I am an engineer, have done my own investigation and measurements into network audio sound quality for trivial UPnP media flows - but of course I established it is entirely implementation and product dependant. I have now created a solution that is devoid of any detectable network impact. It wasnāt overly difficult - but I like nearly all consumer streamers on the market, are using trivial media TCP flow transfers.
Hi Simon,
Thanks for your considered reply, however I donāt think you are quite getting what Iām talking about.
Take a company like Innuos. They build a line of servers from the fairly simple half width Zen to the very sophisticated double box Statement NG, with several products in-between. There is a very significant difference in the sound quality produced at each level, pretty much in line with the Ā£17,000 span of Innuosās price range. The differences between the individual products come down to quantifiable engineering principals, namely:
Power supplies
Power supply topology
Vibration control
Internal cabling
EMI minimization/isolation
Oscillator accuracy
Timing accuracy
Vibration control
Vibration isolation
Component selection (type and quality)
Network interfaces
Essentially a server obtains music files from a network and outputs them to a streamer or DAC. Each of the Innuos servers has the capability to obtain and transmit bit perfect copies of files, so there is no difference in the bit structures produced across the entire product range. But the sound quality very much reflects the degree of engineering incorporated into each server. The better the server executes all the engineering points listed, the better the resulting music sounds, without any changes to the bit structure. So the first question. If not bit structure, what does the server change that can alter the presentation of the music so fundamentally. Bear in mind that these SQ changes apply pretty much equally to any DAC or Streamer that may be connected to the server, Naim included.
Moving on to the next question: if the changes that the Innuos servers perform on the bit stream could also be incorporated into the incoming feed to the server, would you generate the same or similar benefits? In my experience hi-fi operates on a better in = better out basis. The Innuos servers demonstrate exactly this quality when they input their data streams into a streamer or DAC; the more carefully engineered and refined their outgoing data stream, the better the resulting sound quality. So I hypothesised that perhaps the network is just as sensitive to the same engineering improvements that so profoundly influence the Innuos server range. I checked this hypothesis with 2 manufacturers and with my Audiophile IT āadvisorsā who share their knowledge on DIY Computer Audio sites and none could see a reason why it shouldnāt be the case. I conducted literally dozens of upgrades across my entire network, improving cables, power supplies (multiple times), vibration control, mains supply, routers, WAN cables, modems etc. and every single one bar a USB retimer that used a SMPS had the desired effect, sometimes to a jaw dropping degree). I have been upgrading hi-fi systems for roughly 55 years and never did I find a more effective and productive source of improvements as those brought by upgrading the network.
You may think that after several dozen successful upgrades the sound must have been profoundly, utterly and totally transformed and that was exactly the case.
I would sit down, hit play on my IPad and be instantly transported to an entirely different acoustic venue. Even before the music started I had a strong sense of being in an entirely different place, an intimate club, a large hall, a cathedral, an open air stadium, infinite space (electronic music) ā¦ā¦the palpability of the venue, with all its acoustic clues was quite remarkable. And the systemās ability to communicate the fun, spontaneity and emotional message of the music was beyond anything Iād previously heard. When I lost my hearing I truly lost the keys to paradise, but Iām grateful that I did achieve and exceed all my audio goals. Now all thatās left to do is to share my experiences and communicate my findings that networking for IT is not the same as networking for audio, at least not if you want the finest results possible
@Blackmorec And yet you havenāt even touched on the newest flavor of the month, direct attach cable, or DAC, which many, including Taiko, and Uptone and others over at Computer Audiophile are beginning to embrace (so long as your streamer has an sfp input and switch output). They are dirt cheap for the most part, though of course Melco has one on offer now for close to a thousand dollars. Iāve got an $8 used Cisco one on the way to me to compare to the Cisco AOC cable Iām currently using between my opticalModule and opticalRendu. Essentially the DAC is a passive copper cable with SFP connectors at the ends that foregoes the optical conversion.
Hi CP,
Quite right! In fact I did mention it obliquely in the following paragraph;
ā A pioneer in this endeavour, Taiko Audio eventually ended up designing routers and switches specifically for high-end audio due to the fact they could achieve such massive improvements in the final sound quality via this route. They found that something as simple as an RJ45 network cable socket can be substituted to produce less noise, because everywhere on a network where work is done, noise is produced. Reduce that work and you reduce the noise. Its that simpleā
I avoided using its title because I couldnāt remember it and was too lazy to look it up 
What Taiko found was that a DAC interface uses significantly (a lot) less power than an RJ45 interface and therefore produces a lot less noise. The system they were designing was so quiet that the RJ45 interface became one of the major sources of noise.
Apart from it absolutely is of course 
Audio is simply a service carried by the network, and controlled by the network ā¦ there is no magic or special voodoo honestlyā¦ audio is a big part of my professional networking worldā¦ and has been on and off since the late 90s with our early streamed services and replay.
I think in the audiophile enthusiast space there is sometimes some confusion between electrical physical noise and actual data networking service control and managementā¦ the two are differentā¦ and I think it causes with some people erroneous cause and effectā¦ where they may think something is network related, where as in actual fact has nothing to do with data networkingā¦ and more to do with analogue interferencesā¦ and these aspects can get involved from an EM perspective
But I repeat audio in networking often uses fundamental building blocks in networking technologyā¦ there is absolutely no special carve out for our very simple home audio use cases, where for the most part some of the key tools available to help audio services are not used as they are no relevant for our simple hifi needs.
But I always encourage good RF hygiene and suitable managing common mode leakage currents,ā¦ whether it be a coax SPDIF from your TV or Ethernet lead from a consumer network product.
Hi Simon,
Again thanks for the thoughtful reply. I can see a case where we are both correct. Again let me give you an example.
On a bit perfect transmission of data for an IT app, adding something like a PhoenixNET switch will make no difference whatsoever, whereas if the app is audio related youāll hear a major uplift in many, many facets of the music. A large part of the appreciation of the uplift comes from our limbic nervous system, which has to do with emotions, and isnāt something that cognitive thought has much if any direct influence over. Itās very hard to fool the limbic system. The same is true for upgrading a power supply to one with less noise, greater capacity and lower impedance. Upgrading an ethernet cable can have a major influence on the amount of detail heard by a listener. It will have absolutely ZERO effect on any IT related file. The difference in networking for audio only comes about when a data file is converted to analog, then converted to sound pressure waves, then converted to nerve impulses, then converted to a conscious appreciation of tonal patterns that we recognise as music.
The big difference between analog and digital is that in analog the original voltage pattern can only be maintained or made worse by the addition of noise or some form of distortion
In digital, the signal has 2 distinct parts, the actual bit pattern logic and the physical form those bits and packages take. In analog, the original signal can be amplified and frequencies can be adjusted and thatās about it. In Digital the signal can be physically repackaged, physically transformed, physically regenerated, retimed, filtered, stored etc. etc. In short, we have a number of ways to make a digital signal better.
In a typical network the data may be packaged, converted to light pulses, converted to radio waves, converted back to voltages, filtered, retimed, buffered etc. Data can be retransmitted, errors corrected, noise removed etc. and all I am saying is, the better you do all those conversions, filtering, retiming, regeneration of voltages etc. the better the final presentation of the music. A network that is noisy, slow, overloaded etc will not create sound that is as good as one that is operating at the pinnacle of performance. But from an IT perspective there will be no difference whatsoever between the 2 as long as the error rate is within spec.
I respect that you have a lot of music industry experience. By the same token itās taken me since the initial inception of CD to produce music from digital that I actually preferred to any and every analog system Iāve owned and I managed to get to that point only by streaming music through a network that Iād refined to a very high degree, so maybe its the industry that should be taking note?
Getting back to my original point, the refinement of my network may well relate to the multitude of physical noises to which the network is susceptible, indeed that sounds very logical. In that case, all Iām saying is that music benefits hugely when as much of every type of noise can be removed from the data stream. And the best way to do that is by optimizing the network with the goal of removing as much noise as possible while isolating the data stream from external noise contamination.
Hiā¦ thanks yes my professional experience is mostly with industrial/commercial audio and audio network control systems rather than the music industry ā¦
But yes the world needs enthusiasts, or no one will buy these hifi products ā¦ take care.
S
Ah, yes that was oblique, lol. But you are correct. Apparently the Sonore devices run a lot cooler with the DAC cables vs optical. Iāll report back later this week with my findings. Stay tuned.
Itās possible - and even very likely - that these things are one and the same.
Thatās an unfortunate acronym given the proximity to the digital analog converter, or DAC.
Yeah, I could remember the acronym but not its meaning. I thought that using the term DAC related to a cable without an explanation would have been extremely confusing, as in āusing a DAC to connect to your DACā
Yes, but they were meant to live in worlds apart, never to meet, until us crazy audio hobbyists came along that isā¦ If itās something that catches on , referring to them as SFP Twinax cables would be less confusing, for sure.
Replaced the Cisco SFP AOC cable between the opticalModule and opticalRendu with the Cisco Twinax SFP+ DAC cable and holy cow! Who delivered the subwoofer?!! Or in other words, it really lets my 160 do its Naim thing with the bass and mid-bass. Maybe almost so much so that Iām going to have work on some better isolation of my Audio Physic Compacts so as to not overpower the high end so much. I actually have the speakers in bookshelves in my office, which I know isnāt the best, but it is what it isā¦
The DAC cable doesnāt have quite the same airiness of the AOC, but it has an organic meatiness about it and is less fatiguing in the treble, and is a much funner listen imo, esp with older or poorly recorded rock records which could be a bit shrill and anemic with the optical cable. Itās really something else, and the difference was not in the least bit subtle. Just for the fun of it, I may try another inexpensive DAC cable (should I go shorter? or longer - which would take me from 30awg to 24awg?) which may be much more difficult to parse any difference.
Indeed. One of the things that Iām not sure that people realise is that the packet of data containing a small snippet of the music youāre listening to on yourstreamer (or DAC) is not the same one that left the network port of your server (or left the streaming service you use). The packet has been regenerated at each transmission point along the path.
If you use just a single switch in your network, youāll have at least one regeneration of the packet. If youāre playing from a streaming service, the packet has probably been regenerated 10s (or more) times. Which is why thereās not going to be any noise or data corruption in the data.
Kind of, there is no regeneration of a packet payload per se - especially within a subnet or home network - as here one is primarily dealing with frames along a rather simple and static path, and the MTU size will be negotiated by the two hosts as the TCP session is established. A home network may have an MTU size of 1500 for an internal flow.
If one is routing, say across the internet, and one is going via a path where MTU sizes is constrained, such as via a VPN etc, the packet through a router along the path may have to be fragmented by that router to fit into a smaller MTU size (Maximum transmission unit size ) within that path - that is the packet is split into two or more smaller packets
If this IP fragemention of the packet occurs one sent packet routed across the internet will arrive as two or more smaller packets. But unless you are using VPNs with IPSec or similar - this is unlikely to be happening. MTU size is usually negotiated between two peers for a particular flow to avoid this - but some times the application despite this sends a larger packet, or the path changes for a flow, and a packet then can exceed the negotiated MTU size in which case IP fragmentation will occur.
For the internet with typical broadband access - the max negotiated MTU tends to be 1492 at IPv4 and 1452 at IPv6 and this will typically avoid fragmentation issues, and in which case the packet of data containing the snippet of audio samples is achieved as that same snippet of audio samples without any fragmentation.
Now what is more common across the internet - and we saw this a lot with the Naim first gen streamers, less so later, was the stream of packets containing snippets of samples that arrived at the receiving application layer of the streamer above its network transport layer were received in a slightly different order (this doesnāt mean they were necessarily received in a different order by the network itself) to how they were sent, and here the sequence of packet payloads would then have to reconstructed within the session window of the streamer to get the right sequencing. This was often because sometimes the sender wouldnāt receive the confirmation in time from the streamer and so the sender would resend certain packets. Therefore the sequence could be jumbled for a session window - but the TCP allows for this and the streamer restructures the correct sequence of packets using the data it has received - if it canāt itās all thrown away - and the that sequence flow starts again.
Yes, it is about the RF, and this will save you lots of $$$$, and some futile efforts which direct you to the wrong track unless you just simply focus on and take care of these RF issues.