Det är fascinerande hur fördomsfulla en del av er blivit med åldern. Det en gång så nyfikna barnet, som förmodligen ledde er in på PC-bygge och sedan till SweC, har liksom helt dött hos er.
Aldrig funderat på att ...
0. Inse att ämnet är utanför ens kunskapsområde.
1. Sitt tyst och lyssna på de som faktiskt kan något i ämnet, lär av deras diskussioner?
2. Fråga någon kunnigare för att ta reda på mer?
3. Testa själv?
... istället för att leka självutnämnd auktoritet men egentligen bara sitta och ordbajsa och exponera okunnighet?
Genant om ni frågar mig.
Det intressanta är att det inte går att se vilken sida av debatten du står på med inlägget. Är det med mening?
Få människor är genuina experter på både nätverk ner på fysisk nivå, och elektronikdesign med ljudfokus, speciellt på ett så litet forum som SweClockers, så det är inte lätt att hitta en trovärdig källa. Jag har lite erfarenhet av båda (men är absolut inte expert på något av detta) och har svårt att se hur en sån här produkt skulle kunna hjälpa i praktiken.
Det finns så många "skydd" mot bitfel innan det kan orsaka skillnad i ljud.
Först så har alla "streamers" en buffer med ljud, eftersom de spelar från internet och paketförluster och andra störningar alltid kan förekomma. Några sekunder är vanligt som minimum, men YouTube kan ofta dra ner en minut i förväg, om inte mer. Så om vi har nätverksproblem i säg en halv sekund är det oftast inget som hörs.
Säg då att vi har en del jitter i överföringen på vår Ethernet-koppling, som denna produkt ska motverka, så grovt att det mottagaren uppfattar inte är vad sändaren faktiskt skickade, dvs en eller många bitar blev korrupta för att vi saknar denna produkt. Vad händer nu?
Alla Ethernet-ramar ("paket" i vardagssnack, på denna nivå kallas det "frames" på engelska) som skickas har en checksumma, så med extremt hög sannolikhet kommer mottagaren upptäcka detta då checksumman är felaktig. Då kastar den helt enkelt bort ramen.
Påverkar det ljudet? Nej. Sändaren märker efter en kort stund att mottagaren inte svarat att den fick datan, och så skickas den om, ljudbuffern utökas med den nya datan och lyssnaren hade inte en aning att någon data behövdes skickas om.
Nerifrån och upp så har Ethernet en checksumma på all data, sedan har IP en checksumma för delar av paketet (dock inte datan), sedan har TCP och UDP ännu en checksumma på all data. Om någon av dessa 2-3 checksummor är fel så kommer paketet skickas om, så sannolikheten att data kommer fram och är korrupt är väldigt, väldigt låg.
Ethernet-checksumman bör vara fel (dvs påstå att ett meddelande är korrekt när det faktiskt är korrupt) omkring en gång på 2^32, eller en gång på 4.2 miljarder (glöm inte att detta är 4.2 miljarder gånger där överföringen misslyckats, inte så ofta som en gång per 4.2 miljarder överföringar!). Sedan är det två checksummor som körs på lite olika data.
Härifrån är jag mer osäker och spekulerar en del: TCP/UDP bör ha fel omkring en gång på 2^16, och detta lär vara oberoende av den föregående eftersom de har helt olika algoritmer och beräknas på lite olika data (olika headers plus ljuddatan), så i runda slängar 1 på 2^48 bör ett korrupt paket klassas som felfritt av både Ethernet och TCP/UDP.
Skickar man 2^48 paket på 1500 byte var (omkring den vanliga maxgränsen över internet) så är det 422 petabyte -- så nånstans i storleksordningen flera petabyte med korrupt data behövs skickas innan det är sannolikt att någon korrupt data nått mottagaren och skickas vidare till att spelas upp som ljud.
Tar gärna emot kritik om det är några felaktigheter i detta, men jag är ganska övertygad om att poängen kvarstår även efter sådana rättningar: att minska jitter och ge "ännu mer" galvanisk isolation till något som redan är isolerat kommer inte ge bättre ljud, utöver förstås via placebo, konfirmeringsbias och annat.
Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200