Ethernetkabels. Sinds streaming in het high-end segment terecht is gekomen, zien we kabels van praktisch elke fabrikant: Audioquest, Supra, Nordost, Shunyata, Chord, et cetera. Maar ethernet is digitaal. En dan ook nog package based (in tegenstelling tot bijvoorbeeld spdif). Dat kán toch niet fout gaan? Hoe is het dan mogelijk dat we verschillen horen? Wij gaan op onderzoek uit. Bereid u voor om meerdere delen. En nee: wij hebben nog geen antwoorden. En wij weten ook niet waar deze reis eindigt!Â
Toen we van More Music wat Shunyata ethernetkabels op de mat kregen, hadden we twee keuzes: weer gewoon luisteren en een verhaaltje tikken, of iets meer ermee doen. Wij hebben besloten er iets meer mee te doen. We hebben bijvoorbeeld al samples gemaakt en die laten horen via Youtube. Zo kunt u zelf bepalen of u verschillen hoort. Er zijn luisteraars die wel wat (subtiele) verschillen horen. Wij ook. En dat zet ons aan het denken: hoe kan dat? Kortom tijd voor stap twee: een metingen ‘groepstest’.
Maar ja: wat ga je meten? En hoe ga je meten? Dat zijn cruciale vragen. Zeker bij ethernet, want wie een beetje thuis is in netwerkprotocollen, weet dat het nagenoeg onmogelijk is dat er datafouten ontstaan. Dat komt mede door TCP wat een connectie-geörienteerd protocol is en voorzien is van foutcorrectie. In elk datapakket staat waar het vandaan komt, waar het naar toe moet, waar het in de keten thuishoort én een crc-check. Klopt deze niet, dan wordt hij opnieuw verstuurd. Kortom: datafouten zijn bij TCP uitgesloten. Bij UDP niet overigens. Maar ook daar komen datafBaouten in een thuisnetwerk bijna niet voor.
Toch zijn we benieuwd. Want wat als we gaan samplen en samples gaan vergelijken? Is écht elke bit dan hetzelfde? Let’s find out.
De keten
Een ethernetkabel zit doorgaans tussen de streamer en een switch. De uitgang van de streamer kan ofwel digitaal zijn, ofwel analoog als het om een streamer met ingebouwde dac gaat. Om te meten moeten we digitaal werken, want we gaan de samples opnemen. En dat gaat in wav-files. Kortom: wij kunnen het beste een streamer met digitale uitgang pakken.
Nu zijn we eigenwijs en hebben we onze streaming-setup voor YouTube. Dat is een behoorlijk hoogwaardige keten. Denk aan een Grace pre-amp, een Benchmark AD-converter en prima bekabeling. We sluiten in eerste instantie onze Metrum Acoustics Pavane analoog aan op de pre-amp en gaan samplen. We nemen elke keer twee samples op met dezelfde kabel, zodat we kunnen bepalen of deze gelijk zijn. Immers: check en dubbelcheck.
Het resultaat is ronduit onbetrouwbaar. We horen continu verschillen. Ook bij gelijke kabels. Dat kan natuurlijk niet. Een beetje denkwerk leidt tot het feit dat converters nooit exact gelijk werken. En AD-converters ook niet. Kortom: geen sample zal gelijk zijn. Dit werkt niet, omdat we niet weten wat we meten, aangezien er continu variabelen zijn. Tijd voor een compleet digitaal pad.
Via de Baby en licht naar binnen
We pakken onze Metrum Acoustics Baby Ambre. Deze is klein en draagbaar. Deze sluiten we optisch aan op een ESI Maya44 geluidskaart die een optische ingang heeft en ASIO drivers heeft. De ethernetkabel gaat tussen onze Zyxel mediaswitch en de Baby Ambre. Ook de ROON-server is direct aangesloten op deze Zyxel.
We starten Reaper op en stellen alles in op ‘bit perfect’. We pakken een korte track van Aafke Romeijn en nemen van elke kabel twee samples op. We komen dan uiteindelijk op het volgende rijtje:
- Shunyata Alpha
- Shunyata Delta
- Audioquest Cinnamon
- Audioquest Pearl
- Standaard UTP
We hebben de Venom niet in deze test meegenomen omdat dit een goed genoeg beeld geeft van de eventuele verschillen. U ziet hieronder de screenshots van de software in werking.
De methode van werken is dus als volgt geweest:
- Baby Ambre haalt het signaal via Roon naar binnen
- Baby Ambre stuurt via een Audioquest Vodka het signaal naar een ESI Maya44 geluidskaart
- Reaper haalt via ASIO het signaal binnen en maakt een 16 bit / 44.1 kHz sample (bron is ook 16/44.1)
- Wij slaan de samples op en importeren deze in een Adobe Audition multitrack
- We leggen alles samples op sampleniveau gelijk (dat kan in Audition).
- Ter controle muten we alle samples op twee na.
- We inverten één track 180 graden en spelen alles af. Er moet stilte zijn als alles gelijk is. (Dat was het geval)
- We vergelijken de samples met elkaar in Foobar 2000 (er is een wav comparison plugin).
Conclusie
We hebben bij geen enkele ethernetkabel verschillen gemeten in het digitale domein. UTP, Audioquest, Shunyata… alle kabels presteren in het digitale domein gelijk. Elke bit in de sample is gelijk… letterlijk: 0 verschil. Bekijk de resultaten in de screenshots maar.
Maar we kunnen nu nog steeds niet concluderen dat ethernetkabels geen invloed hebben. Immers: we zijn binnen het digitale domein gebleven. En dan speelt iets als jitter geen rol. En ‘ruis’ ook niet echt. Kortom: wat we geleerd hebben, is dat we niet meer hoeven te zoeken in het digitale domein: er is géén packet loss. En er is ook geen verschil in kabels zolang we digitaal blijven werken: dat bewijzen de éxact gelijke samples. En dat verklaart ook dat in feite de rest van het netwerk totaal niet boeiend is als het gaat om audiokwaliteit. Upgrade alleen de kabel naar de streamer. De rest kan eigenlijk geen invloed hebben.
We wilden u graag meenemen op deze reis. Wij gaan door met wroeten!
Hallo Jaap,
Leuk onderzoek.
De digitale inhoud van de bestanden klopt. Maar het zou heel goed kunnen dat er gebruik gemaakt is van de CRC, voor foutcorrectie, en misschien het file-system ook wel, net voor de opslag op de HD.
Eerdere testen hebben al laten zien dat er geen hertransmissies zijn op het netwerk, dat is een actie van laag 3 (IP) van het OSI-model, maar laag 2 (ethernet) corrigeert ook, evenals de protocollen op de hogere lagen.
Bij streaming worden moeten die correcties “near” real-time worden uitgevoerd, wat enige extra inspanning kost in processing; en misschien doorwerkt via de voeding cq aarde van de schakelingen.
met vriendelijke groet, Maarten
Mijn ervaring is dat het 0% aan de bitstream ligt. Het probleem zit in de noise die wordt meegevoerd. De dac chip raakt hierdoor waarschijnlijk in de stress en functioneert (of interpreteert) hierdoor minder goed. Ik heb dit aangetoond met metingen in het analoge domein. De metingen hadden een lengte tot 20milliseconden. De data werd vele malen achter elkaar aan de dac chip gevoerd en er waren kleine tot grote verschillen zichtbaar.
De fouten / verschillen traden op tussen een geoptimaliseerd netwerk en een normaal netwerk.
https://forum.psaudio.com/t/ethernet-cables-and-sound/11297/399
Groetjes,
Wijnand
Overigens zullen audio ethernet kabel leveranciers niet blij zijn met deze uitslag. Weg is hun verdien model.
Eerlijkheid is belangrijk. Kan zomaar zijn dat in Deel-2 er wel wat uit komt. Vervolg staat in de planning.
Mogelijk, ik verwacht als er iets uitkomt dat dat meer terug te voeren is op gebruikte connectoren, ook die in het apparaat en hoe die connectoren zijn vastgemaakt. De kabel zelf zal weinig uitmaken. Een slechte verbinding tussen kabel en connector, een slechte verbinding tussen connector en ethernet kaart of slechte ethernet kaart levert altijd ellende op. Je daar helemaal niet veel geld voor kwijt te zijn. Mooiste zou zijn als je kunt werken met een toongenerator en twee oscilloscopen. Dan kun je precies meten wat de kabel in gaat en wat er uitkomt en dat bij verschillende frequenties. Je kunt zelfs in het audio apparaat meten welke signaal er op de print ingang binnenkomt. Ik zie uitdagingen?
Hallo Jaap,
Bedankt weer voor deze heldere sessie.
De elektrische toleranties voor het versturen van data blijven in alle gevallen binnen de norm, dus zijn de eindresultaten identiek. Dat is het mooie van digitale technieken. Analoog zul je verschillen in spanning meten, maar die doen er dan niet meer toe.
Dat je verschillen blijft horen zit dus in de keten. Ik denk dat de Switch je zwakke schakel is.
Domweg omdat je het verkeer in de switch niet kunt controleren. De switch bepaalt op geheel eigen wijze de verdeling van de datastromen over de verschillende processoren afhankelijk van de hoeveelheid beschikbare uitgangen.
En omdat er iedere keer een andere elektrische last op het netwerk staat, door dat continue aan en uit van de processoren, hoor je verschil. Het is dus ruis van de wispelturige switch.
Switch op een andere groep in de meterkast aansluiten, of gewoon weglaten. Ik kan me niet indenken dat jullie op kantoor zoveel data produceren dat een Switch de uitkomst is voor een betere verdeling van de netwerklast. Maar ik kan me vergissen natuurlijk.
Een gewone netwerk HUB zal voldoen en geeft veel minder gedoe.
Veel luisterplezier,
Theo
Beste Theo. Een hub maakt een groot collision domein. Dat is nooit wenselijk. Daarbij zijn hubs niet meer echt te koop naar mijn weten ;).
Collisions horen bij ethernet, maar daar is wat op gevonden. Ethernet maakt gebruik van Carrier Sense Multiple Access with Collision Detection protocol. Dat laatste, CD, is belangrijk want dat zorgt er voor dat collisions netjes worden verwerkt. switches zijn interessant voor grote netwerken waarbij je niet tegen de beperkingen van ethernet aan wilt lopen. honderden werkstations op één ethernet segment gaat ten koste van de snelheid, dan heeft een switch nut. overigens heb je ook nog broadcast verkeer wat altijd op alle segmenten terecht komt. als je dat wilt tegenhouden moet je weer een router tussen de netwerk segmenten plaatsen. De paar aansluitingen die normaal bij iemand thuis op het netwerk zitten (en wellicht ook bij jullie) maakt de noodzaak van een switch overbodig en zelfs nadelig. ik zou het een keer uittesten als ik jullie was.
Wat je ook nog kan doen is terug gaan in de tijd en een tokenring netwerk aanleggen. Superieur aan Ethernet, geen collisions en elke zender wacht netje op zijn beurt. ideaal
CSMACD is vooral bij hubs belangrijk. Switches maken per poort een apart collision domain.
Je geeft aan dat bij ons switches niet nodig zijn / overbodig zijn. Maar hoe gaan we dan onze werkstations, accesspoints en streamers aansluiten? Op een hub? Hubs zijn per defintie niet handig i.v.m collisions. Een fatsoenlijke switch – zelfs semi-managed – koop je voor nog geen 100 euro als je 12 poorten nodig hebt. Ik zie niet in waarom je geen switch zou willen. Een ‘domme’ swtich kost een paar tientjes. Kortom: ik zou niet weten waarom je nu nog een hub zou plaatsen. De laatste hub die ik heb geplaatst is geloof ik begin 2000. Kortom: 20 jaar geleden ofzo.
Ook switches gebruiken csmacd, want dat is namelijk een protocol wat inherent bij ethernet hoort. Verschil met een hub is dat op 1 switch port maar 1 device zit, dat werkt bij een hub anders. Maar ging er mij om dat er een punt werd gemaakt van collisions alsof dat erg is. Dat is namelijk alleen vervelend als er veel collisions zijn en dat komt vaak door een kapotte ethernet adapter of teveel stations of 1 netwerk. Maar zelfs dan hoeft het geen probleem te zijn. De bovenliggende protocollen ip en tcp zorgen ervoor dat er geen pakketjes verloren gaan. Audio devices hebben meer dan genoeg buffer capaciteit om eventuele collision problemen op te vangen. In een goed werkend ethernet netwerk leveren collisons zelden een groot probleem op. Punt is wel dat in de huis, tuin en keuken netwerkjes er vaak slecht materiaal wordt gebruikt en dan krijg je dus wel ellende.
Eens!
Beste Jaap,
Leuk artikel over metingen aan digitale kabels maar dat er geen verschil is gevonden is niet verrassend want dat is door Jacco Dekkers al aangetoond in 2012. Zie: http://amorgignitamorem.nl/xmb/viewthread.php?tid=5.
Hartelijke groet,
JanM
Beste Jan,
We hebben dit ook met USB gedaan. Ook geen verschil.
Punt is wel: je blijft binnen het digitale domein. En dat is voor een complete test – dus met óók d/a-conversie – niet genoeg. Je neemt geen jitter mee namelijk. Maar feit is: er zijn geen bitverschillen. En dat zegt ook wat. Ik probeer nu een methode te vinden waarbij we ook de ‘analoge’ kant mee kunnen pakken. Dat is echter heel lastig vanwege talloze variabelen.