The Sound of Ethernet

rs-qt
Aktiver Hersteller
Beiträge: 133
Registriert: 25.03.2015, 12:07
Wohnort: Ratingen

Beitrag von rs-qt »

Milhouse hat geschrieben: 16.06.2022, 14:14 Ich habe das noch nicht gemessen, aber gehört und das klingt sehr sehr gut.

Hierdurch werden dann zwar Störungen des Ankommenden Netzes nicht mehr abgeführt, aber es können auch keine Störungen von der Masse zum Endgerät wandern.

Bzgl. der Abführung der Ankommenden Störungen habe ich einen anderen Weg schon länger gefunden, den ich mal demnächst berichten werde.
Hallo Eric,

bin gespannt was du aus dem "Kleenen" noch rauskitzelst.
Wenn du magst kann ich dir mal eine Sellarz Clock zusenden, falls du sie im TP mal testen möchtest. Sie liegt momentan hier eh nur rum.

VG
Ralf
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Für mich die Schlüsselstelle im Video https://www.youtube.com/watch?v=BbRF8z8dQFU ab 14:09:
after the buffer the signal has to be sent to the chip that does the digital to analog conversion. During this transport jitter can be introduced again. I already mentioned a noise ground pane and varying voltages at power rails. This is why the EtherRegen has the secondary side completely isolated from the primary side, including the power supply.
Prima. Nehmen wir mal an, das genau das die Lösung ist. Der EtherRegen macht, angenommen, eine saubere Entkopplung aller möglichen Einflüsse, von mir aus auch bzgl. einer Gleichtaktstörung.
Und nun?
Was tut der EtherRegen eigentlich als Hauptaufgabe? Er leitet einen ankommenden Ethernet-Datenstrom weiter. Und zwar wiederum als Ethernet-Datenstrom. Und der kommt nun bei einem DAC (Dante, Ravenna ...) an. Oder bei einem zwischengeschalteten Rechner.
Und was passiert da?
Genau, die Datenpakete werden wiederum sortiert und gepuffert. Und dann findet wiederum was ganz Wichtiges statt:
after the buffer the signal has to be sent to the chip that does the digital to analog conversion. During this transport jitter can be introduced again.
Merkt Ihr was? Die gesamte Qualität hängt davon ab, wie der DAC konstruiert ist. Spätestens wenn der DAC-Chip das I2S-Signal bekommt, könnte genau dieses im besten Fall "completely isolated from the primary side, including the power supply" sein. Also ohne Jitter oder Noise.

Logisch geschlußfolgert mag also der audiophile Switch helfen. Oder auch nicht. Je nachdem was im DAC stattfindet. Kein Wunder, dass es soviel unterschiedliche Meinungen gibt, wenn jeder am Ende ein anderes Geraffel verwendet. Hausversorgung mit eingeschlossen.

Übrigens: das macht die Arbeit von Eric nicht notwendigerweise wertlos. Allerdings bin ich mittlerweile der Meinung es könnte informativer sein, wenn Eric unterschiedlichste Switches testet, dann aber gleich z.B. die Jittermessung beim I2S-Signal vor dem DAC-Chip durchführt. Wenn sich hier abhängig vom Switch was ändert, egal ob auf der seriellen Clock- oder Datenleitung, dann würde der Zusammenhang möglicherweise verständlicher und klarer.

Grüsse
Uli
Bild
Dilbert
Aktiver Hörer
Beiträge: 253
Registriert: 01.02.2013, 16:28

Beitrag von Dilbert »

Hallo Uli

aber wo liegt der mögliche Einfluß des Switches auf das, was letzendlich der DAC-Chip als Signale erhält? Die kommen doch aus dem Puffer.... ggf. sogar über USB....wieder nur HF?

Grüße

Frank
Bild
Milhouse
inaktiv
Beiträge: 644
Registriert: 28.12.2020, 09:58

Beitrag von Milhouse »

uli.brueggemann hat geschrieben: 16.06.2022, 15:48 Merkt Ihr was? Die gesamte Qualität hängt davon ab, wie der DAC konstruiert ist. Spätestens wenn der DAC-Chip das I2S-Signal bekommt, könnte genau dieses im besten Fall "completely isolated from the primary side, including the power supply" sein. Also ohne Jitter oder Noise.

Logisch geschlußfolgert mag also der audiophile Switch helfen. Oder auch nicht. Je nachdem was im DAC stattfindet. Kein Wunder, dass es soviel unterschiedliche Meinungen gibt, wenn jeder am Ende ein anderes Geraffel verwendet. Hausversorgung mit eingeschlossen.
Hallo Ulli,

unbeachtet, das ich schon sehr oft bei datentechnischen Erklärung von Hans Beekhuyzen so meine ? hatte.
Aber letztendlich geht es doch darum vom DAC alle mögliche Störungen fernzuhalten - entweder welche, die Jitter kurz vor der Wandlung bedingen können oder (ich weis, da streiten sich ja schon wieder die Geister) HF Noise, der nach der Wandlung durch Demodulierung wirkt.

Wenn ein DAC, wie bei mir der RME ADI 2 DAC (bitte hier nicht ein weiters Fass a la "DAC vom Ramschtisch kann ja nix werden" aufmachen), unter allen Umständen mit seinem Test angibt, das er alle Bits der Daten ohne Fehler bekommt, es aber Klangunterschiede bei unterschiedlicher Ethernet Infrastruktur zum Streamer gibt, dann kann ich mir das leider immer noch nur mit Störungen erklären, die die Wandlung stören oder danach wirken. Von daher glaube ich, das in einer Jitter MEssung des zuspieler Protokolls/Physik nichts zu sehen sein wird, sondern z.B. bei USB Störungen über die Schirmung und welche im Gleichtakt :cheers: beim Differnzialsignal von USB .
Dilbert hat geschrieben: 16.06.2022, 16:13 aber wo liegt der mögliche Einfluß des Switches auf das, was letzendlich der DAC-Chip als Signale erhält? Die kommen doch aus dem Puffer.... ggf. sogar über USB....wieder nur HF?
Das ist meine These, denn mir ist leider immer noch nicht klar, welche Auswirkung ein Ethernet Jitter Wert für den DAC haben soll.

Beste Grüsse,

Eric
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Eric,

die Frage ist unter anderem, ob durch HF oder andere Störungen die Clock des DACs „jittert“. Das am DAC Chip anliegende I2S Signal könnte Aufschluss geben. Ist das sinnvoll machbar?

Grüße,
Andree
Bild
Milhouse
inaktiv
Beiträge: 644
Registriert: 28.12.2020, 09:58

Beitrag von Milhouse »

Hallo Andree,

ich könnte mal schauen, wie ich das USB Signal (Sorry - I2S habe ich kein Setup für) messe - aber bzgl. der Messung der Gleichtaktstörungen bin ich mir noch unsicher, ob das so einfach geht, da m.E. bei USB keine Transformer verwendet werden, bei denen ich einfach an der Mittelanzapfung messen kann. Müsste dann wieder mit der Math Funktion arbeiten, bei der ich keine FFT machen kann.

Vielleicht hat ja da jemand eine Idee?

By the Way versteh ich die ganze Aufregung eigentlich nicht.
Störungen auf Signalleitungen gelten doch allgemein als Feind des Audiophilen. Jetzt wissen wir, das es eine zusätzliche Einflugschneise gibt. Da müssten doch alle gleich, auch ohne technisches Verständnis, dabei sein, zu schauen, wie man die minimieren kann - schon etwas suspekt.....

Beste Grüsse,

Eric
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Vielleicht hilft auch ein Gedankenmodell zum Verständnis:
Angenommen sei ein Buch mit einem netten Inhalt. Der Inhalt ist damit fest, die enthaltene Information liegt unveränderlich vor. Nun liest jemand das Buch vor. Wenn das unterschiedliche Leute tun, ist schon mal klar, dass sich das immer unterschiedlich anhören wird. Aber selbst wenn das immer dieselbe Person ist, wird sich das jedesmal anders anhören. Logisch, die Lesegeschwindigkeit wird reichlich variieren.
Also kommt jemand auf die Idee, das Vorlesen zu takten. Und prima, das klappt den im Gedankenmodell auch prima. Es sei denn, die Versorgung des Vorlesers schwankt. Wenn er Hunger hat oder zu viel gegessen hat, gibt es Momente wo er den Takt doch nicht so einhält.

Nichtsdestotrotz ist die Information im Buch ok und am Ende kommt sogar alles fehlerfrei beim Hörer an. Nur mit dem Tempo mag es ncht perfekt sein. Aber nehmen wir mal an auch das bekommen wir hin.
Nun erweitern wir das Gedankenmodell ein bisschen. Das Buch ist noch nicht fertig. Da wird noch während des Vorlesens reingeschrieben. Am besten klappt das dann noch, wenn es zwei Bereiche gibt, einen Abschnitt, aus dem gelesen wird und einen in den man schreibt. Wird schnell genug geschrieben, kann der Vorleser in den neuen Abschnitt wechseln, wenn er mit seinem Abschnitt fertig ist. Das nennt man dann Wechselpuffer.

Was aber, wenn Vorleser und Buchschreiber mehr oder weniger gleichzeitig auf derselben Seite schreiben. Dann müssen sie sich schnell genug auf ein wechselseitiges Arbeiten einigen. Und es könnte auch passieren, dass sich der Vorleser vom Schreiber gestört fühlt.
Die Wahrscheinlichkeit, dass alles reibungsfrei läuft, nimmt in diesem Sinn immer mehr ab.

Nun könnt Ihr so manche Ansätze einer optimalen Audiowiedergabe mit dieser Geschichte reflektieren. Zum Beispiel Einlesen des kompletten Tracks in den RAM. Wechselpuffer bei Asio. Quasi gleichzeitiges (=scheibchenweiser Echtzeitbetrieb) Beschreiben/Auslesen von Ethernet-Puffern in Switch und DAC oder USB-Puffern. Whatever. Qualität der Stromversorgung. Noise auf der Masse.

Für mein Verständnis macht es nur Sinn, wenn man rückwärts beginnt. Wenn am DAC-Chip alles perfekt ist (gemeint sind Eingangssignale, Clock und Versorgung), dann sollte alles gegeben sein, dass der Ausgang ok ist. Damit ist die Aufbereitung dieser Signale das Thema. Und dann geht es immer weiter nach vorn. Natürlich darf nicht vergessen werden, wie Störungen auf der Masse bestmöglichst vermieden oder abgeleitet werden. Und wie einstrahlfest der DAC bzw. dessen Ausgang gegenüber HF sind. Ist das nicht gegeben, reagiert der DAC mit Sicherheit wahlfrei auf vorgelagerte Komponenten wie eben Switches. Dann stört eben der "Buchschreiber" den "Vorleser" eben mehr regelmässig (der Vorleser kann sich besser drauf einstellen) oder eben mehr unregelmäßig (hoppla, Überraschung).

Grüsse
Uli

PS @ Eric: mir ist nicht ganz klar, dass Du nun mit USB argumentiert hast (Sound of Ethernet). Ok, ist letztlich auch eine serielle Paketübertragung.
Bild
music is my escape
Aktiver Hörer
Beiträge: 1528
Registriert: 03.07.2012, 10:56
Wohnort: Leipzig

Beitrag von music is my escape »

uli.brueggemann hat geschrieben: 16.06.2022, 15:48 Merkt Ihr was? Die gesamte Qualität hängt davon ab, wie der DAC konstruiert ist. Spätestens wenn der DAC-Chip das I2S-Signal bekommt, könnte genau dieses im besten Fall "completely isolated from the primary side, including the power supply" sein. Also ohne Jitter oder Noise.

Logisch geschlußfolgert mag also der audiophile Switch helfen. Oder auch nicht. Je nachdem was im DAC stattfindet. Kein Wunder, dass es soviel unterschiedliche Meinungen gibt, wenn jeder am Ende ein anderes Geraffel verwendet. Hausversorgung mit eingeschlossen.
Hallo Uli,

genau so. Weil es aber in der Praxis keine ideal funktionierenden DACs zu geben scheint, auch wenn praktisch jeder Hersteller, egal ob Hifi oder Profi, seit Anbeginn der Zeit bei jeder neuen Gerätegeneration aufs Neue behauptet, bei speziell seinem DAC-Konstrukt wäre die Digitalquelle (genauso wie der angeschlossene Empfänger) nun mittlerweile aber wirklich vollkommen egal und es klänge immer super und gleich und transparent und ergreifend, wird von bewundernswert laienhaft-tüftelnder Kundenseite notgedrungenermaßen mit vermeintlicher Fehlervermeidung, -ausmerzung etc... aber auch teils unfreiweilliger, teils gewollter -kompensation durch Nebenprodukte dieser zumeist nicht sonderlich wissenschaftlich, empirisch ermittelten Maßnahmen versucht, auf der Strecke dahin und beim Strom und was weiß ich noch wo das individuell Bestmögliche herauszuholen. Dass man dabei Irrtümern aufliegt, sowohl in Ursache als auch Wirkung, und sich im Handumdrehen allerlei kleine Scharlatane finden, welche ebenfalls vor Selbsttäuschung nicht gefeit bei diesen Problemchen gegen gewisses Entgelt nur allzu gern Lösungen suggerieren, liegt leider in der Natur der Sache, führt aber auch zu einer gewissen Entwicklung.

Horsts Versinnbildlichung mittels des maximalen Jitterbudgets (ich mache für mich ganz großspurig gleich ein allgemeines Fehlerbudget draus), bis zu dessen Erreichen (am DAC - oder wars doch erst am Ohr? :wink: ) ebenfalls individuell mit allen dazugehörigen Parametern wie das jeweilige unterschiedlich reagierende Equipment, der Raum, die Hörgewöhnung/ -konditionierung, die eigene Leidensfähigkeit etc... alles im noch grünen Bereich und erst darüber hinaus kritisch ist, trifft den verrosteten, verdreckten Bit-Nagel in meinen Augen ziemlich genau auf den Kopf, auch weil es sich auf jeden Einzelbereich der Übertragung und Verarbeitung herunterbrechen lässt und es so erlaubt, das Einzelne zu sehen ohne das Gesamte aus dem Auge zu verlieren (und umgekehrt).


MfG, Thomas

P.S.: wo im Leben ist das eigentlich nicht so, das mit dem individuell maximalen Fehlerbudget? :wink: :mrgreen:
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Eric,

sorry, eventuell habe ich dich mit der I2S Anfrage verwirrt. Meine Frage ging eher in die Richtung: Kann man an geeigneter Stelle in einem DAC messen, ob z.B. die von dir verfolgten Gleichtaktstörungen einen Einfluss auf die DAC-Clock haben. Das könnte z.B. der Takt der Clock selbst sein, oder eben das I2S-Signal, das dem DAC-Chip intern zugeführt wird. Eventuell kann man auch schauen, ob es zu Störungen an der Versorgungsspannung der Clock kommt. Alternativ kann man natürlich auch Testsignale wie das Dunn'sche Jittertestsignal spielen, aufnehmen und dann auswerten. Problem hier wären durch den ADC eingebrachte Fehler, die je nach Stärke (evtl. ließe sich hier künstlich ein stärkeres Störsignal beaufschlagen?) den DAC-Fehler maskieren. Aber das wäre das, was letztlich verstärkt und zu Gehör gebracht wird.

Für die Auswertung solcher PCM-Aufnahmen stehe ich gerne zur Verfügung.

Grüße,
Andree
Bild
Milhouse
inaktiv
Beiträge: 644
Registriert: 28.12.2020, 09:58

Beitrag von Milhouse »

uli.brueggemann hat geschrieben: 16.06.2022, 17:51 Was aber, wenn Vorleser und Buchschreiber mehr oder weniger gleichzeitig auf derselben Seite schreiben. Dann müssen sie sich schnell genug auf ein wechselseitiges Arbeiten einigen. Und es könnte auch passieren, dass sich der Vorleser vom Schreiber gestört fühlt.
Die Wahrscheinlichkeit, dass alles reibungsfrei läuft, nimmt in diesem Sinn immer mehr ab.

Nun könnt Ihr so manche Ansätze einer optimalen Audiowiedergabe mit dieser Geschichte reflektieren. Zum Beispiel Einlesen des kompletten Tracks in den RAM. Wechselpuffer bei Asio. Quasi gleichzeitiges (=scheibchenweiser Echtzeitbetrieb) Beschreiben/Auslesen von Ethernet-Puffern in Switch und DAC oder USB-Puffern. Whatever. Qualität der Stromversorgung. Noise auf der Masse.

Für mein Verständnis macht es nur Sinn, wenn man rückwärts beginnt. Wenn am DAC-Chip alles perfekt ist (gemeint sind Eingangssignale, Clock und Versorgung), dann sollte alles gegeben sein, dass der Ausgang ok ist. Damit ist die Aufbereitung dieser Signale das Thema. Und dann geht es immer weiter nach vorn. Natürlich darf nicht vergessen werden, wie Störungen auf der Masse bestmöglichst vermieden oder abgeleitet werden. Und wie einstrahlfest der DAC bzw. dessen Ausgang gegenüber HF sind. Ist das nicht gegeben, reagiert der DAC mit Sicherheit wahlfrei auf vorgelagerte Komponenten wie eben Switches. Dann stört eben der "Buchschreiber" den "Vorleser" eben mehr regelmässig (der Vorleser kann sich besser drauf einstellen) oder eben mehr unregelmäßig (hoppla, Überraschung).

Grüsse
Uli

PS @ Eric: mir ist nicht ganz klar, dass Du nun mit USB argumentiert hast (Sound of Ethernet). Ok, ist letztlich auch eine serielle Paketübertragung.
Hallo Uli,

das mit dem Buch-Vorlese-Vergleich kenne ich etwas anders aus einer Diskussion, die ich mit Galen Gareis (der hat die Bonded Technologie bei Belden eingeführt) bzgl. Kabeldesign hatte - leider finde ich die gerade nicht. Die wurde aber von Ihm für den geregelten Datentransfer benutzt ;-)

Dafür aber diese vielleicht interessantere Aussage von Ihm:
Galen Gareis hat geschrieben:Here is where noise can be a problem, it isnt the effect on the Ethernet accuracy, that remains bit perfect except under the worst of sitations, it is the effect on the system clock. The system clock controls the digital interpolation coming out of the DA block. A bad clock introduces jitter and non linear quantization noise in the X and Y axis. This moves the closest, and most accurate, value with respect to time and amplitude.

This clock error is what impacts the sound. It is feasible that different Ethernet cables COULD introduce noise that MIGHT effect the system clock. A galvanic isolator might mitigate the issue if several things are true; the cable even has noise on it, it gets past the filters in the NIC card and it gets into the system clock circuit block…past the built-in noise safeguards in that critical block.

This isn’t the “sound” of an Ethernet cable. It, if “it” is really happening, is the sound of the system clocks response to noise induced quantization errors. And the noise is assumed to be there, and introduced by the Ethernet block.
This could be proven with noise injection and detection on the system clock. Are we really after a real problem, or failing to define that we have one?
Und er meint diesbezüglich nicht die Ethernet Clock, sondern die DAC System Clock.

Trotz netter Vergleiche und Geschichten von rostigen Nägeln habe ich immer noch kein Vertrauen in diese Theorien ;-)

Warum ich USB zum Messen in Betracht nehme?

a) Um die Auswirkungen der entdeckten Störungen von Ethernet hier zu überprüfen.

Bzgl. Deines Vorschlags vorne in der Kette anzufangen denke ich, das dies der richtige es, wenn wir uns die Aufgabe stellen, den besten Klang zu erhalten.
Die Aufgabenstellung, die ich mir in diesem Thread gegeben habe ist, welchen Beitrag leistet hier Ethernet.

P.S.: Grüsse von Ralf H. Er hat gerade mit meinen Tips seine neue Netzinfrastruktur auf Störungsreduzierung implementier und ist total begeister.
Bild
Markush
Aktiver Hörer
Beiträge: 362
Registriert: 02.08.2021, 11:44

Beitrag von Markush »

Hallo Eric,

es ist alleine goldwert deine Links und Zitate zu sehen.
Sehr schön, dass du dich hier weltweit in die Thematik vertiefst und damit auch den Horizont / Bandbreite der Wahrnehmung für alle Teilnehmer bzw. Leser hier erweiterst.

Ich denke für einen guten Fortschritt und weitere Erkenntnissee wird es definitiv die Bereitschaft vieler brauchen auch bisherige Ansichten und Konventionen neu zu überdenken und auch über Bord zu werfen.

Ich freue mich schon auf mehr.
Hast du eigentlich deinen aktuellen „status quo deiner Empfehlungen zum Netzwerk Setup“ in einem Artikel oder Link wo? Das Feedback von Ralf hört sich ja fantastisch an.

Liebe Grüße
Markus
Bild
Trinnov
Aktiver Hörer
Beiträge: 971
Registriert: 13.11.2009, 19:02

Beitrag von Trinnov »

Dilbert hat geschrieben: 16.06.2022, 15:13 Hallo Horst

ich mache mir die Erklärung ganz einfach: meine didaktische Schulbuch-Weisheit sagt mir, das man von einer vollständige Datenintegrität über die komplette TCP/IP-Ethernetstrecke ausgehen muß. Der Jitter spielt dabei aufgrund der paketorientierten Übertragung und der damit einhergehenden Pufferung der Daten sowie des Recklocking bis zum Reenderer keinerlei Rolle.
Du schreibst, dass der Jitter keinen Einfluss hat. Die Frage ist, was meinst du konkret mit „keinen Einfluß“. Ich sage, er hat aufgrund der eingesetzten Technik sowie dem TCP Protokoll keinen Einfluß auf die Datenintegrität , jedoch möglicherweise schon auf die Qualität der Audiowiedergabe in „on the fly“ z.B. vom NAS abgespielten Audio Tracks.
Die Gründe dafür sind ja aktuell dank Eric in Klärung.

Dilbert hat geschrieben: 16.06.2022, 15:13 Mit asynchronem USB kann es lediglich noch einen Einfluß von Clock-Jitter im DAC selbst geben.
Wenn dem wirklich so wäre, dann wäre die Qualität der Ethernetübertragung also die Produktqualität völlig egal.
Das bedeutet, jeder der eine asynchrone USB-Übertragung betreibt, müsste sich um eine Optimierung der Ethernetstrecke nicht mehr kümmern. Haben die Nutzer da draußen tatsächlich diese Erfahrung gemacht?

Dilbert hat geschrieben: 16.06.2022, 15:13 Es gibt für mich auch keinen Grund anzunehmen, das gleichzeitiges Schreiben und Lesen eines Puffers Auswirkungen auf das Timing haben sollte, schon vor 35 Jahren war das bei unseren HW-Spezialisten selbst bei alten Mikrocontrollern auf Basis eines TI9900 keinerlei Thema.
Um das ausreichend genau zu erklären machen wir leider ein neues Fass auf. Da es vermutlich doch ein paar Leute interessieren wird, will ich dazu wenigstens ein paar Zeilen schreiben, auch wenn es OT ist. Wie du vielleicht weißt, können CPUs im Gegensatz zu FPGAs Threads nur sequenziell also nacheinander abarbeiten.
Parallel, also zeitgleich kann nur erfolgen was gleichzeitig aufgrund von mehreren zur Verfügung stehenden physikalischen Kernen gerechnet werden kann. Bei mir ist Hyperthreading deaktiviert. Selbst ein aktiviertes HT schafft in vielen Fällen bereits eine Nervosität der Audiowiedergabe.
Ein gutes Beispiel ist ein Windows OS, das nebenher noch Audio ausspielen darf.
Vielleicht mein Lieblingsthema. Siehe auch den Thread Windows im RAM.
Man muss sich nur in einem Prozessmonitor Tool anschauen, was Windows so alles zeitgleich bzw. genauer gesagt nacheinander tut. Nebenher soll es auch noch Audio ausspielen und das auch noch „zeitgleich“. Meiner Meinung nach ist auch das Jitter. Selbst ein Audio-Buffer wird dann mit ziemlicher Sicherheit nicht in einem Stück beschrieben und geleert.
Da das nicht gut klingt, lohnt es sich das Windows für die Audio Anwendung entsprechend „abzuspecken“ und zusätzlich Windows im RAM zu betreiben. Es sollten im Taskmonitor nicht mehr als 350 Tasks übrig bleiben. Diese beiden Maßnahmen reduzieren den Systemjitter und damit den Jitter auf der späteren SPDIF Leitung. Der messtechnische Nachweis ist wie wir wissen sehr schwierig. Ich bin einverstanden das nicht als gegeben zu behandeln sondern als These.
OT Modus aus, obwohl unvollständig erklärt.

Dilbert hat geschrieben: 16.06.2022, 15:13 Bleibt - wie beschrieben - nur noch der Noise über Kabel und Grounding, aber da ist eine Vorhersage schwierig. Wenn das tatsächlich über 200mA sein können (mea Culpa, ich hatte das auch als rein qualitative Messungen betrachtet), dann muß man wohl die nachfolgende analoge Schaltung vollständig verstehen und durchmessen, um zu verstehen ob das einen Einfluß auf das analoge Signal haben kann.
Ich weiß nicht wie diese Zahl „200mA“ zustandekommt. Ich muss eingestehen, dass ich nichts über die Details eurer Messung weiß, die 200mA Strom fließen lässt.
Als Größenordnung für Noise kenne ich nur µV, mV oder Volt. Sollten das Potentialunterschiede zwischen Komponenten sein, erzeugen die in meinem Setup einen gemessenen Potentialausgleichstrom über meinen Signalkabelvarianten USB, AES und Balanced Audio von nur 300 – 500 Nano-Ampere (gemessen natürlich ohne gemeinsame Schutzleiterverbindung). Für die Leute, die die Größenordnungen nicht einsortieren können: 200mA wären dann 200.000.000 Nano-Ampere.
Bei nur 300 – 500 Nano-Ampere (0,3 – 0,5 µA) kann man das wichtige Thema Ausgleichsströme / Modulation der über Verbindungskabel transportierten Signale durch Potentialausgleichsströme getrost ignorieren. Der Weg dorthin ist leider auch sehr speziell. Jedenfalls benötigt es nicht zwingend einen Akkubetrieb.

Dilbert hat geschrieben: 16.06.2022, 15:13 Oder man muß direkt den analogen Ausgang messen, um zu sehen ob sich der analoge Noise bei Änderungen der Ethernet-Komponenten ebenfalls ändert. Das hatte Uli ja schon mal für Ethernet-Isolatoren angefangen, mit dem Ergebniss, das sich die daraus resultierenden Änderungen in einem Bereich von < -100 dB bewegen.
Ein im Detail sehr schwieriges Unterfangen! Das hier genauer zu erklären würde den Rahmen sprengen und wäre OT.

Dilbert hat geschrieben: 16.06.2022, 15:13 Ja und jetzt mein Zauberspruch: "Solange die gehörten und beschriebene Änderungen nicht ein einziges mal in einem einfachen Blindtest zweifelsfrei detektiert wurden, ist das Thema Ethernet/NAS etc. für mich nicht relevant, da kümmere ich mich lieber um die Optimierung der Aufstellung und der Korrekturfilter".
Einverstanden! Auch mir ist die Macht der Autosuggestion bewusst. Darüber müssen wir nicht streiten.

Dilbert hat geschrieben: 16.06.2022, 15:13 Wenn es begründetet Einwände gegen diese These gibt, nicht sicher, ob wir da nicht besser einen neuen Fred aufmachen sollten.
Wird für mich zeitlich aktuell nicht umsetzbar sein. Vor allem nicht, wenn man es in einer gewissen Ausführlichkeit macht. Das war heute eher mal wieder eine Ausnahme, weil es Leute gab, die sich das gewünscht haben. Ja, ich verschone euch nun wieder vor meinen unsinnigen Behauptungen, Thesen und Ideen.

Viele Grüße,
Horst
Milhouse
inaktiv
Beiträge: 644
Registriert: 28.12.2020, 09:58

Beitrag von Milhouse »

Markush hat geschrieben: 16.06.2022, 21:29 Hast du eigentlich deinen aktuellen „status quo deiner Empfehlungen zum Netzwerk Setup“ in einem Artikel oder Link wo?
Hallo Markus,

ich habe da eigentlich noch keine abschließende umfassende Empfehlung die ich allgemeingültig verkünden möchte.
Im Bereich Kabel und auch im Bereich Isolatoren bin ich da noch am testen und weiterhin am konstruieren.
Eine Vergleichsmessung von den Kabeln steht ja auch noch aus und ein Etherregen und die Meraki Switche sind auch noch im Zulauf.

Aber "wer gackert muss auch ein Ei legen" heist es bei uns - daher werde ich meine aktuellen Empfehlungen abgeleitet von meinen Erfahrungen zusammenstellen und in den Mess-Thread im OEM einstellen. Sorry für die Cross-Kommunikation über zwei Foren hinweg, aber zum einen habe ich sehr viel bei beiden Foren gelernt und fände es schade mich aus einem zu verabschieden und letztendlich ist dies doch gelebtes Know-How Sharing.

Beste Grüsse,

Eric
Bild
Markush
Aktiver Hörer
Beiträge: 362
Registriert: 02.08.2021, 11:44

Beitrag von Markush »

Hallo Eric,

alles klar - das ist ja auch absolut verständlich.
Ich hoffe sowieso auch im Sharing Economy / Schwarmintelligenz Zeitalter ist es auch förderlich wenn mehrere kluge Köpfe wertvolle Inputs leisten, auch über Forengrenzen & Co. hinweg.

Vielleicht auch interessant unter https://devialetchat.com/Thread-OCXO-os ... #pid105922 bzw der Link zu MSB Tech.

Liebe Grüße
Markus
Bild
Milhouse
inaktiv
Beiträge: 644
Registriert: 28.12.2020, 09:58

Beitrag von Milhouse »

Markush hat geschrieben: 16.06.2022, 22:52 Vielleicht auch interessant unter https://devialetchat.com/Thread-OCXO-os ... #pid105922 bzw der Link zu MSB Tech.
Hi Markus,

ich zitiere mal von der MSB Seite: https://www.msbtechnology.com/dacs/clock-options/
Why are external clocks sub-optimal for digital audio?
A clock signal is a fast moving precision electrical signal and is extremely sensitive to added noise or distortion. Each time it’s buffered or transmitted, a portion of its precision is lost. Even if a small amount of noise couples into the clocks, jitter will increase dramatically. It might still be an accurate clock, but accuracy is of little performance benefit to digital audio. A clock sent over an ultra-high quality cable will still increase its jitter considerably. The best solution is to create the lowest jitter clock as close to the DAC as possible.
Das ist genau der Grund, weshalb ich Clock Upgrades (egal wo) mit ihren zusätzlichen Kabeln, Lötstellen und/oder Steckverbindern kritisch gegenüber stehe.

Beste Grüsse,

Eric
Bild
Gesperrt