Ethernetkabels, de CAT vangen (deel 1)



De eerste test

De eerste test destijds bestond uit het uitrollen van 12 meter AudioQuest Pearl Ethernetkabel van mijn centrale switch naar een UnitiQute. Audioquest Pearl CAT7Daarmee terug kerend naar één enkele switch, in combinatie met de lange Pearl kabel en zo was het een hoorbaar stapje terug ten opzichte van switches en Supra kabel. Tot ik een gewone CAT-5 gebruikte van 12 meter als alternatief voor de Pearl, toen bleek de Pearl al wel een heel stuk beter dan computershop kabel. Toch gaf ook de Pearl minder goed details door naar de Naim UnitiQute dan Supra deed, werd de klank lichter van toon, was er minder impact en het stereobeeld werd kleiner. Van AudioQuest kreeg ik naast de Pearl een zelfde lengte Cinnamon en dat leverde een verrassing op. Met die kabel op de plaats van de Pearl speelde ik “One million bicycles” van de Katie Melua CD “Live at the O2 Arena” opnieuw en opeens kreeg het aanwezige, opgenomen publiek een grotere invloed op de beleving. Het publiek was er steeds al, maar kwam tot leven en bestond niet meer uit een massa maar uit individuen.

En weer terug…

Toen ik de zaak weer aansloot als voorheen: NAS->Supra->switch->CAT-5->switch->Supra->Naim beoordeelde ik de Cinnamon als beter dan de Pearl, veel beter dan de CAT-5, ook beter dan de twee switches met Supra. Katie Melua - Live at The O2 ArenaDaarmee trok ik de voorzichtige conclusie dat het laatste stuk kabel naar de speler op zijn minst belangrijk is, zo niet het meest belangrijk. Wat doet de kabel tussen de switches onderling eigenlijk? Eenvoudig te proberen door de Cinnamon tussen de switches te prikken. Dat maakte weer een verschil in positieve zin: meer hoorbare details, meer gemak, betere scheiding tussen instrumenten onderling. Zoals een opgenomen orgel dat meer naar de voorgrond kwam, een hoorbaar rijkere klank van een fluit en de meer opwindende stem van Katie.

Opnamefoutjes zoals Katie die maakt als ze tegen de microfoon stoot zorgden voor een meer intense beleving van de muziek nu ze meer opvielen.

De file was een FLAC, geript van een CD in 16bit 44.1kHz en dat kost echt geen moeite om de data ervan te transporteren over een Gigabit netwerk heen. Meer bandbreedte slokt een studio master van Ceacily Norby op in 24bit 96kHz. Drie maal zoveel data kost haar “The dead princes”. Nog steeds een eitje.

De beste als laatste

Ik had ook nog een kort stuk Cinnamon en dat paste mooi tussen de remote switch en de UnitiQute, met de lange Cinnamon nog steeds tussen de switches. Als laatste stukje klonk een Supra in vergelijk met Cinnamon donkerder en zorgde voor een grotere druk in het laag, helaas niet lekker strak, maar opgeblazen en rommelig. Van het zelfde laken een pak met de Katie Melua geripte file. Zo kwam ik tot de conclusie dat het beste resultaat te verkrijgen was door voor alle kabels Cinnamon te kiezen, van en naar de eindpunten en tussen de switches. In ieder geval Cinnamon te gebruiken als verbinding naar de speler, terwijl het gebruik van één centrale switch ten opzichte van twee switches (centraal en remote) op die manier niet van belang is. Om geld te besparen en toch ten opzichte van CAT-5 te verbeteren bedacht ik dat Pearl tussen de switches en Cinnamon naar de nodes een oplossing kon zijn. Gouden regel: de beste kabel (vaak de duurste) altijd tussen de switch en de node gebruiken.

De laatste schakel(aar)

Audioquest Cinnamon CAT7Steeds heb ik 12 meter kabels gebruikt, of vanaf mijn centrale switch via een remote switch naar de UnitiQute, of vanaf de centrale switch rechtstreeks naar de speler. Wat nu als ik nog een switch neerzet en tussen de laatste switch en de UnitiQute een heel korte kabel gebruik? Drie switches op een rij, waartussen alleen standaard CAT-5 kabel zit. Ik kon nu vier types vergelijken op dat laatste stukje: standaard CAT-5, Supra, AudioQuest Pearl en Cinnamon. Gebruikte muziek was: “Paper airplane” van Alison Krauss & Union Station, gekocht bij HDTracks als WAV 24/96.

Van CAT- naar Pearl

Toen ik van CAT-5 overging naar Pearl kwam de band pas echt binnen: meer ruimte, minder stress, meer soepel en lekker vloeiend. Moeilijk te geloven, toch echt waar. Muziek bloeide op als een zonnebloem in de zomerzon. De volgende kabel, Supra, was verder verfijnd en maakte meer werk van de gitaarsnaren in de opname. Een weg terug naar standaard CAT-5 werd weggevaagd. Audioquest Cinnamon was in deze opstelling de kabel met de meeste “lucht”, verloor in de detailweergave van de Supra. Op een korte lengte werd de Supra favoriet geacht. Maar om heel eerlijk te zijn, ik bedacht dat het moeilijk zou worden om de Cinnamon en de Supra op de lange termijn uit elkaar te houden, Supra vergaf wat meer, Cinnamon klonk wat harder en agressiever. Kleine verschillen bleven het.

NAD M52 data opslag

Met de bovenstaande resultaten in het achterhoofd ontkoppelde ik de NAD M52 data opslag van mijn M50 speler, zodat ik muziek ging spelen vanaf mijn NAS over Ethernet en niet langer over USB tussen de M52 en M50. De situatie was gelijk aan de laatste opstelling in de studeerkamer:

NAS->Supra->switch->CAT-5->switch->CAT-5->M50. Ooit had hier als laatste stukje een Supra gezeten, maar na de komst van de M52 was de enige data die over dat stukje kabel ging het verplaatsen van files of het sturen van commando’s naar de M50. Veel nut heeft een duurdere kabel dan niet meer. Voor die tijd, dus bestanden spelend vanaf de NAS via de M50, gaf de Supra een wel een forse verbetering ten opzichte van een computershop CAT-5. NAD M52 muziekopslag

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.

  • >