Ethernetkabels, de CAT vangen (deel 1)



Op verzoek van de redactie van Audio Creative heb ik een paar artikelen over de hoorbare verschillen tussen Ethernetkabels vertaald en met mate aangepast voor de leesbaarheid, artikelen die ik eerder schreef voor een Engelse uitgever (2012-2013). De apparatuur die wordt genoemd is deels nog in mijn bezit, deels vervangen, maar de conclusies zijn niet anders dan destijds. Ethernet kabels laten in een goed systeem hun signatuur achter als er muziek overheen wordt getransporteerd. Dat kan de lezer belangrijk vinden, onbelangrijk of zelfs verwijzen naar het land der fabelen, het is mijn constatering en die van mede luisteraars en auteurs die over audio schrijven.

Netwerk

Een stukje achtergrondinformatie

Een stukje achtergrondinformatie is misschien op zijn plaats. Met muziek en audio ben ik nu ruim 50 jaar intensief bezig. In die tijd heb ik ooit in een audiowinkel gewerkt op zaterdagen om wat bij te verdienen. Midden tot eind jaren ’70 was het luisteren naar verschillen in kabels iets dat in de kinderschoenen stond. Wij deden dat al wel en concludeerden tegen de algemene opinie in dat er wel degelijk hoorbaar verschil bestond tussen 2×2,5mm2 goedkoop tweelingsnoer en 2×2,5mm2 kabel met een andere isolatie en parallel geleiders die verder uit elkaar lagen.

Nu kijken weinig mensen op van het kiezen voor een goede kabel. Nu gaat diezelfde discussie over Ethernetkabels en komen dezelfde soort argumenten van voor- en tegenstanders omhoog. Omdat we het over Ethernetkabels gaan hebben kan ik ook vermelden dat ik in de jaren ’80 ben gaan werken in de automatisering en heb meegemaakt dat ARCnet en Token Ring de slag verloren aan Ethernet.

Van data naar muziek

Netwerk switchOoit gingen de pakketten nog over coax Ethernet, later over twisted pair kabel met de bekende aanduidingen als CAT-5, CAT-6 en CAT-7. De afgelopen 15 jaar was ik werkzaam als netwerkbeheerder van een groot landelijk netwerk met honderden routers en duizenden switches, lokaal opgesteld en in een paar datacenters. Ik ben dus verre van onbekend met Ethernet, data transport, 10-Megabit tot aan back bone Gigabit verbindingen, protocollen en alles wat er meer komt kijken in een dergelijk netwerk. Ik weet dus ook goed hoeveel data je over een CAT-5 kabel kunt jagen zonder een bit te verliezen en zonder een enkele fout op een switchpoort te genereren.

Sceptisch

Toch bewijzen mijn oren dat data met muziek iets anders is aan het eind van de rit (de luidspreker) dan data waar een computer mee kan laten zien hoe een tekst zal worden. Gezien mijn achtergrond van netwerkbeheerder was ik zeer sceptisch over vermeende, hoorbare verschillen in Ethernetkabels, het audiofiele deel van mijn geest liet het niet los en vandaar het eigen onderzoek dat hier beschreven gaat worden.

Hoe is het begonnen?

Linksys SE2800 Gigabit Netwerk switchLaat ik beginnen met het beschrijven van mijn netwerkje thuis zoals het ooit begon. Centraal staat nog steeds een router, gekoppeld aan een Gigabit switch van Linksys (type SE2800) met een standaard computershop kabel. Aan die switch zaten eveneens een NAS en een Vortexbox mediaspeler, destijds gekoppeld met Supra CAT-7+ kabels. Vanuit deze centrale switch gebruikte ik standaard CAT-5 kabels naar drie andere switches, één in de huiskamer en twee in de studeerkamer. Vanuit die huiskamerswitch ging een stuk Supra kabel van 1 meter naar een NAD M50 digitale muziekspeler en vanuit de eerste studeerkamerswitch een lengte van 8 meter naar een Naim UnitiQute. De keuze voor Supra kwam voort uit: betaalbaar, betrouwbaar, verkrijgbaar. Naim Unitiqute

Meerdere switches

Die keuze voor meerdere switches in huis komt voort vanuit mijn professie, beter een lokale switch dan vele lange kabels. Bovendien zorgen switches voor een lagere jitter waarde op je netwerk, ze her-klokken, verminderen het aantal re-transmissies en versterken het signaal. Omdat ik thuis geen managed omgeving heb met meerdere VLAN’s heb ik niet geïnvesteerd in dure Cisco apparatuur zoals mijn werkgever gewoon was, maar in betaalbare Linksys producten die minder stroom gebruiken en niet actief koelen met jankende ventilators.

René van Es

René van Es is een muziek- en audioliefhebber in hart en nieren. Ooit besmet geraakt op 12-jarige leeftijd met het virus kan hij het niet laten om zijn ervaringen te delen via papier en on-line media. Na een aantal zelfbouw projecten in het verleden is voor hem de nadruk meer en meer komen te liggen op kant-en-klare producten.

  • Wat ik in mijn werk geleerd heb is dat we eigenlijk niets weten. Zo ook in deze test. Wat precies de oorzaak is weten we niet. We kunnen er naar gissen maar hoorbaar is het. Er zullen wel weer allerlei profeten over gaan oreren maar dat laat ik maar aan me voorbij gaan. In ieder geval een zeer interessante test. Ga zo door !

    • Via een kabel worden er nullen en enen verstuurd tussen source en target.
      De overgang tussen 0>1 en 1>0 is echter niet tijdloos.
      De schakelsnelheid (SS) van de source is afhankelijk van de snelheid van de driver.
      Vervolgens wordt SS beïnvloedt door de belasting van de kabel en target.
      SS wordt dus trager, afhankelijk van o.a. de kabel.
      In de target wordt op een bepaald spanningsniveau overgeschakeld van 0>1 of van 1>0.
      Dit is bij elke target anders. De uit de target komende breedte van de ‘1’ en ‘0’ worden dus beïnvloedt.
      De genoemde breedte is dus vóór een kabel anders dan ná de kabel + target.
      Dit is in de grootte order van enkele picoseconde of nanoseconde.
      Of dit hoorbaar is?
      Hoe wordt de klok opnieuw gegenereerd? Hoe stabiel is die? Jitter ?
      Hoe goed (snel) is de switch?
      Hoe goed of slecht een kabel of switch ook is: de aantallen enen en nullen worden niet aangetast.
      Ook de volgorde van de enen en nullen verandert dan niet.
      De verschillen MOETEN dus iets te maken hebben met de flanksnelheid van de getransporteerde bitstroom.
      Er zullen dus verschillen te horen zijn afhankelijk van de kabel, lengte, swtich etc.

  • Als de data niet aangetast wordt door de kabels (is dat uitgesloten in het onderzoek ?), dan is het enige dat overblijft jitter. Er is nog wat werk te doen aan de ontvangende kant (DAC)…….

  • Waar ik nu wel erg benieuwd naar ben is: wat als je een muziekstuk van computer A naar computer B stuurt en weer terug onder een andere naam, om vervolgens deze data digitaal te vergelijken (op bit niveau). Zijn er dan verschillen?

    Zijn er geen verschillen, dan mogen we twee dingen concluderen er a. gehoormatig verschillen optreden en deze niet veroorzaakt worden door de kabels maar ergens anders in de keten bron – DA.

    Dit lijkt me wel een belangrijke constatering voordat we ons WEER in een peperdure kabeloorlog gaan begeven terwijl er misschien een gemakkelijk(er) te realiseren logische oplossing te realiseren is (bv bufferen, ontkoppelen en onafhankelijk maken van transport en verwerking c.q DA).

    Ik krijg de indruk dat we ons met z’n allen gezellig (weer) op de transport laag gaan storten en met z’n allen (weer) gaan hobbyen met kabels. Wie het OSI model bekijkt ziet dat er naast veel hardware ook veel software/protocollen/algoritmes komen kijken (en de muziek moet twee keer door deze laag).

    En laten we eerlijk zijn, is een logische en/of structurele oplossing niet véél goedkoper

    Twan.

    https://nl.wikipedia.org/wiki/OSI-model

    • Volledig met je eens, ga eerst maar eens zelf een kabel maken van Belden Cat7 en zorg dat de afscherming NIET verbonden wordt met de plug die in je streamer of muziek PC gaat (DE reden dat er pijlen op een kabel staan) dus een stukje krimpkous of tape toepassen, dit geeft al een dermate grote verbetering dat ik daar eerst mee zou beginnen.

      • DE afscherming mag geen stroom voeren. Moet dus aan een kant (de target) los liggen.
        Dit geldt ook voor de zgn tulpverbindingen in het analoge gebied;

  • Een prachtig verhaal. Ik heb ooit een bij demonstratie van Audioquest de verschillen in lan kabels kunnen horen en heb naar aanleiding daarvan een Forest van mijn Nas naar de switch en een Vodka van de switch naar de computer aangeschaft. De Forest vervangen door een Vodka zodat er voor en na de switch een Vokda zat, gaf een minder fraai geluid. Heel vreemd. Audioquest adviseert zelf ook de beste lan kabel aan het eind te zetten, dus tussen switch en computer. Het maakt in mijn set zelfs uit hoe de stekker van de voeding van zowel de switch als de Nas in het stopcontact zitten.
    Ik vraag mij af of er klankverschillen zitten tussen switch’en en Nas’sen. Misschien ook eens leuk om uit te testen…. Het houdt de gemoederen lekker bezig.
    Ik hou het er op dat we een leuke en interessante hobby hebben en vergeet niet om lekker naar de muziek te luisteren.
    Jan.

  • Rene roept in het artikel dat lange kabels slechter is dan een switch vlakbij. Dat is ook begrijpelijk want inductie en capaciteit, knikken in de kabel en daardoor wisselende impedantie kunnen de zaken slechter maken. Volgens mij kan Dick wel een meetopstelling maken en waarbij de data van de lange kabel en de data uit een switch te vergelijken zijn. Wel dienen de beide systemen te worden afgesloten met 100 Ohm. Vervolgens kun je op een snelle 2 kanaals scope de hellingen (bandbreedte) van de flanken zien. Hoe slapper die hellingen des te lastiger voor de hardware om vast te stellen of dat een 1 of een 0 is en met Rene te spreken of er soep van gekookt kan worden.

  • Hoi René en Dick,
    Interessant artikel. Ben net bezig met een heroriëntatie op streaming en ook de rol van NAS, switch en kabels daarbij. Heb al een simpele switch dichtbij mijn NAS en streamer staan. In deze switch gaat een ongeveer 15 meter lange ethernet kabel die vanuit het kpn punt in de meterkast komt.
    Een paar vragen dus:
    1. Moet deze lange ethernetkabel die naar de switch in mijn audiomeubel gaat ook beter vervangen worden door een betere kabel?
    2. Welke switches voor niet al te veel geld zijn good for the job?
    3. Vanuit de switch twee korte Supra cat 8 naar de NAS en naar de streamer is jullie advies?

    Groeten,
    Frank

  • Buiten kijf, kabels tussen apparaten, van welke aard ook, en overal waar je wat kan in(uit pluggen, doen altijd iets met het geluid…
    Maar… Van mij 2 puntjes om over na te denken (causaliteiten) en verder te experimentieren?
    1. Ik denk, de enen en nullen of het bestaan daarvan, zijn het probleem niet. Die komen vanzelf, gecorrigeerd of niet, maar met meer of minder jitter (dank Guido) en of veroorzaakte aard(lus) storingen in de analoge keten erachter. Voor beide punten is daar naar oplossingen te zoeken. De response met DIY cat7 kabel en de mantel niet aansluiten duidt in die richting. Het thema signaal aarde en net-aarde en de diverse verbindingen is een nog veel meer underground thema als de zichtbare verkabeling overigens. Signaal aarde en net-aarde zijn in de meeste (single ended) geluidsinstallaties duidelijk met-en in-elkaar verwikkeld. Daar hoef je niet lang over na te denken om invloed te zien (en te horen). En denk nu weer aan NET-USB-Ethernet kabels die diverse apparaten verbinden met aarde verbindingen.

    2. Veel players hebben een locaal geheugen waar van de data opslag de file wordt getransporteerd. Tijdens het afspelen van de muziek kan de overdracht over ethernet natuurlijk geen rol meer spelen. Mogelijk wel het feit, DAT er een kabel aanzit. Trek maar eens los tijdens het afspelen en je weet meer. Nu wordt natuurlijk de USB kabel punt van aandacht (en daar is inderdaad ook veel te halen)

  • Wat verdraait interessant is dit!
    Basic OSI kennis nodig (zie wiki). Data is data. Integriteit gewaarborgd door tcp of als udp gebruikt wordt door de applicatie, als de bouwer dat nodig vindt. Streaming protocollen zullen dus gezien het broadcasting karakter en derhalve gebruik vanl udp hier zelf iets voor moeten regelen.

    Wat kan hoorbaar zijn?
    Vervorming van blokgolven is hier niet relevant (tenzij het zo erg is dat dataverlies optreed en Retransmits nodig zijn), dat word op de onderste osi-laag (physical) afgevangen. Wat wel?
    -Benodigde Retransmits van blokken data (in transport protocol of app) : geeft ‘hickups’ als real time dataoverdracht verwacht wordt.
    – gedurende de overdracht wisselende dataoverdracht tijden (zeg maar jitter) : zelfde issue maar minder aantoonbaar/duidelijk

    Beiden zouden door voldoende buffering aan de Streaming-client zijde afgevangen moeten kunnen worden.

    Vraag: welke streaming toepassing gebruikt Rene hier? Levert dit protocol de bonodigde data integriteit en buffering? Of wordt deels op onderliggende (transport) protocollen vertrouwd (tcp/smb/..)?

    Afijn, eindelijk weer eens iets nieuws te beschouwen.. Ik kijk zeer uit naar deel 2!

  • Leuk artikel, erg interessant. Bij mij komen bij het lezen wat gedachtes naar boven. Een digitale koppeling zoals een Ethernet interface heeft natuurlijk ook een aarding referentiepunt. Uit de analoge audio weten we al dat de manier waarop geaard wordt extreem veel uitmaakt in geluids detaillering en ruimtelijkheid en ook de afscherming van bijvoorbeeld audio interlinks heeft veel invloed. Dus ik heb wel een beeld bij de opmerking van Dirk dat de afscherming van een ethernetkabel loskoppelen een enorme geluidsverbetering geeft. Zou het niet zo zijn dat de geluidsverbeteringen in analoge audio ook (deels-) gelden in de digitale audio? Zoals audioquest kabels (lees luchtkabel ipv kabel met een plastic mantel). In mijn dCS classic set maakt een firewire koppeling via een “air” audioquest kabel extreem veel verschil (geen Ethernet, maar wel data…). En het galvanisch ontkoppelen van de Ethernet aarde tussen de Nas en de DAC om de computerrommel-aarde van de NAS en switches niet als input te hebben voor de DAC? Dan zou een Ethernet LAN fiber kabel voor verbetering moeten kunnen zorgen in het netwerk-pad… Onontgonnen terrein lijkt mij, erg interessant! Verder denk ik dat Jitter inderdaad de grote boosdoener is in digitale ethernet koppelingen. De data zelf zou consistent moeten blijven, maar de timing van de data is zeker zo cruciaal.

  • Oei, interessante website hier, maar dit gaat toch wat te ver. Kun je je voorstellen hoe slecht Tidal niet moet klinken na duizenden klometers onder de grond, aftakkingen, en komt binnen via goedkope modem…
    Sorry, is erover. Ondertussen geniet ik van Plex streaming over ouderwetse goedkope Cat5e kabel, klinkt perfect.

    • Ha Hans,
      Hier moet ik jou ongelijk in geven. Twee weken geleden zijn Marco en ik bij Doede Douma op bezoek geweest, de man van de DDDAC1794 NOS DAC. In zijn luisterruimte hebben we verschillende netwerkkabels en routers met elkaar vergeleken. De winst bij de betere, helaas ook duurdere, kabels is echt niet mis, sterker nog: zelfs rondweg overtuigend. We hebben onze gastheer voor het weekend met rode oortjes achter gelaten. Ik hoef niet te vertellen wat hij een paar dagen later vertelde… Inderdaad, geen weg terug en de nieuwe bekabeling was besteld.

      Het punt is vaak niet dat mensen het niet kunnen of willen horen. Niet ieders budget is toereikend, dat is vaak het grootste struikelblok. En daar is helemaal niks mis mee is. Iedereen moet prioriteiten stellen in zijn leven en geld is een schaars goed.

  • Als ik dit zo lees, dan moet de overdracht via WIFi toch echt perfect zijn? Geen invloed van kabels en reclocking in de apparatuur zelf.
    Ik zou wel eens een test willen zien waarbij op bit niveau wordt gekeken naar de signalen. Dus een digitale kopie maken over de ene bekabeling en de andere bekabeling. Verder valt op dat er vooral blocking switches worden gebruikt, de totale bandbreedte van de switch is lager dan het totaal van de aangesloten poorten. Dit moet een vroeger verschil uitmaken dan kabels. Ook raar dat er kabel van tientallen euro’s worden gebruikt en switches van 20 euro….Er zal echt wel invloed zijn van kabels, maar zeker niet op het klankbeeld en klankkleur, dat zou betekenen dat ethernetkabels iets toevoegen of weglaten in het digitale signaal, waarbij het signaal na conversie dus met name positief verandert, terwijl er geen logica in de keten aanwezig is om dit te detecteren en corrigeren in positieve zin.

  • De integriteit van de data is gegarandeerd, anders zou er geen programma kunnen draaien zonder (willekeurige) fouten. Zoals eerder vermeld, zorgt TCP (transportprotocol) ervoor, dat wat aan de ene kant verzonden wordt, er aan de andere kant weer uitkomt. Dat is tenminste zo bij normale netwerkcomponenten. Een vraag zou kunnen zijn of de fabrikanten van streamers het OSI-model volledig geïmplementeerd hebben.

  • >