h0e hat geschrieben: ↑16.06.2022, 08:56
Liebe Leute,
bitte drauf achten, dass es hier um Ethernet geht.
Bitte nicht ständig zu DAC, Spdif etc. abschweifen, denn das ist hier nicht das Thema!
Wenn jemand etwas zum Thema Jitter bei paketorientierter Übertragung beitragen kann wäre das allerdings klasse.
Grüsse Jürgen
Hallo Jürgen,
ich denke die Präsentation eines Erklärungsansatz der Wirkmechanismen des
kompletten Weges angefangen von z.B. einem auf einem NAS liegenden Audio Track bis zum qualitativ gesehen mehr oder weniger perfekten Ergebnis am Ausgang der D/A-Wandlung wird es hier im Forum nach meiner Einschätzung nicht geben. Der für mich hauptsächliche Grund eines nicht gelingenden Lösungsansatzes ist die in Bezug auf audiophile Stereowiedergabe nicht restlos geklärte Wirkweise von Speicherung in Datenpuffern sowie in Speicher-Chips.
Wer nicht will dass er angreifbar ist, wirft einfach nur einen Halbsatz, der zudem leider wie du bereits sagtest nicht viel mit dem Thread Thema zu tun hat, in den Thread und ist somit immer in grünen Bereich. Von den anderen verlangt man gleichzeitig eine fundierte wissenschaftliche Ableitung, damit man in deren Beitrag dann garantiert etwas gefunden werden kann, mit dem sich der Schreiber dann die Finger verbrennt.
Mich erinnert das Verhalten hier im Forum leider an das Beispiel mit dem Reh und dem Jäger.
Manche möchten ein unvorsichtiges Reh auf die Lichtung treiben, damit die 3 bis 5 auf dem Hochstuhl mit der Flinte im Anschlag wartenden Jäger sofort drauflos schießen können um somit ihren maximalen Spaß zu haben. Das ist leider schon lange so und hält mittlerweile einige sehr geschätzte Forumskollegen vom Schreiben ab. Somit muss logischerweise das fachliche Schreibniveau im Forum leiden.
Was sollte jemand davon haben hier Lösungsansätze zu präsentieren, solange die Disziplin im Forum so miserabel ist.
Stellt jemand etwas in Frage, dann ist er ja eh immer der Böse und die Betroffenen weinen sich dann teilweise in anderen Foren aus, um dann konkret über AH-Mitglieder herzuziehen. Kann man machen, muss man aber nicht. Ich zumindest mache das nicht, da ich es vom sozialen Aspekt her für unangemessen halte. Schade für denjenigen, der sich hingesetzt hat um einen Beitrag zu schreiben statt nur Links anzubieten.
Ich möchte das von vielen ungeliebte Wort „Jitter“ eigentlich gar nicht zu sehr strapazieren, aber man kommt einfach nicht drum herum.
Wenn jemand das Vorhandensein von Jitter anerkennt, wird er ja gleich zur „Jitterfraktion“ abgestempelt. Man muss es nicht Jitter nennen und auch nicht Zeit-„Fehler“, denn zumindest in der Ethernet Domäne gibt es normalerweise keine Fehler, wenn man diese Aussage auf die Datenintegrität bezieht.
Es gibt für die komplette Ethernet Übertragung ein gewisses Jitter Budget (ja Jitter tritt auf !!) und daher ist, wenn man innerhalb dieses Budgets bleibt eine Datenintegrität gewährleistet. Das Budget ist dafür da, um auch bei vielen Hops (hintereinanderschalten von Switches) trotz der vielen Störeinflüsse, Potentialunterschiede und der je nach Störungsart diversen Arten von daraus resultierendem Jitter bzw. „Zeitvariationen“ eine Datenintegrität zu gewährleisten.
Nach meinem Verständnis wird Noise in einer digitalen Übertragung
immer zu einer Variation auf der Zeitachse führen. Für die Übertragung der Daten mittels Datenbusse, ob jetzt differentielle Busse oder nicht, ist nur die „Qualität“ der Flanken relevant. Noise sehen wir bei Messungen insbesondere auf dem Impulsdach, aber kaum in den Flanken. Es ist jedoch genauso erwiesen wie auch die Erde keine Scheibe ist, dass der vorhandene Betrag von Noise die Flanke in ihrer zeitlichen Position immerwährend modulieren wird. Das heißt, die Position der Flanke bleibt über die Zeit nicht stabil. Das wird dann sehr gerne sogar von den Wissenschaftlern !! als Jitter bezeichnet. Das heißt die Ursache ist immer Noise, eventuell kombiniert mit Potentialunterschieden zwischen den untereinander verbundenen Komponenten. Daraus wird dann eine Zeitvariation durch Modulation der Flanken.
Um das gegebene Jitter Budget der Übertragung nicht zu sehr zu strapazieren wird mittels, PLLs, Clock Recovery und einigem mehr das „Auge“ des Edge Eye Diagramms immer wieder aufgepäppelt, damit es sich nicht zu weit schließt und somit außerhalb des Budget ist. Siehe dazu die im Anhang verlinkte wissenschaftliche Artikel.
Zudem ist ein differentieller Bus, wie er bei der Ethernet Übertragung Standard ist, gut geeignet um auch bei längeren Übertragungswegen die Vorteile, die ein TCP Protokoll gegenüber dem ungeprüften UDP Protokoll hat, nicht zu sehr zu strapazieren. Grundsätzlich hebt sich ein Großteil der über den Bus mitgeführten Störungen dann dank Differenzverstärker im Empfänger bereits auf. Das gilt bekanntermaßen aber nicht für alle Störungen. Damit wären wir wieder bei CM Störungen. Aber das will ich hier nicht auch noch vertiefen.
Da ich das Wort „Lesekompetenz“ als Werkzeug der Abwertung von Forumskollegen im Gegensatz zu anderen hier nicht in meinem Wortschatz habe und auch nicht haben möchte, wünsche ich mir einfach stattdessen, dass mein wollwollend und freundlich gemeinter Beitrag helfe die Zusammenhänge und Wirkmechanismen etwas genauer zu verstehen.
Jetzt werden sicher entsetzt einige die Augen aufreißen.
Für mein eigenes Setup habe ich aktuell keine Eile die Ethernetstrecke zu optimieren.
Möglicherweise aufgrund des massiv optimierten Audio-PCs und Singxer SU-1 DDCs , unter anderem der Verwendung von OCXOs als Taktreferenz im DDC (die ausführliche Aufzählung der Änderungen wäre sehr lang!), bin ich sogar mit der Wiedergabe von Files, die über WLAN in den Rechner kommen, sehr zufrieden. Grundvoraussetzung ist jedoch das Laden des kompletten Tracks in den Arbeitsspeicher des Audio-PCs, bevor ich die Wiedergabe starte. Das ist bei hochwertigem Musikmaterial richtig gut im Gegensatz zu einer Netzwerk-Wiedergabe quasi on the fly.
Ein Erklärungsansatz, ich betone dass ich
Ansatz geschrieben habe, ist das Vorhandensein eines „Jitter Budgets“ in der gesamten Audiokette. Das heißt auf Deutsch dass für einen Zuhörer bis zu einem gewissen Betrag an Gesamtjitter angenehm klingen wird. Wird dieses durch einen suboptimalen Audio-PC bzw. Streamer und der nachfolgenden Kette, die sich um die Erzeugung des PCM-Signals und der D/A-Wandlung kümmert, nicht bereits überstrapaziert, hat man mehr von seinem Budget für die Ethernet Übertragung übrig. Auch wenn die Bufferung mittels laden in den Arbeitsspeicher das ankommende Signal nicht perfektionieren kann. Auch ein minderwertiges (jitterbehaftetes ?) Audio-File strapaziert das Jitter Budget.
Für sehr aussagekräftig halte ich auch die Tatsache, dass man eine hochwertige Qualität von Audio-Clips übertragen als WAV oder FLAC Datei ohne Einbußen über das Internet (z.B. Dropbox) übertragen kann. Bei diesem Übertragungsprozess habe ich keinerlei Einfluss auf die auf dem kompletten Übertragungsweg eingesetzten Switche, Leitungen und Router. Trotzdem kommt das File in korrekter identischer audiophiler Clip Qualität beim Empfänger an.
Ich kann die beteiligten Providern ja nicht darum bitten, dass sie ihre Datenübertragungsstrecken nach audiophilen Grundsätzen optimieren sollen.
Das ist wie gesagt auch nicht notwendig, wie die Praxis zeigt.
Wenn wir darüber nachdenken, stellen wir fest, dass wir mit diesen von vielen wahrgenommenen Klangabstrichen aufgrund nicht optimierter inhouse Netzwerke immer nur dann zu kämpfen haben, wenn es um eine direkte Wiedergabe geht also wieder quasi on the fly.
Daher wage ich die Behauptung dass die ganze Ethernet Optimiererei der falsche Ansatz ist. Punkt!
Der richtige Ansatz wäre möglichweise eine konsequentere Herangehensweise an das Thema Bufferung / Zwischenspeicherung des Tracks.
Zwecks weiterem Studium der Wirkzusammenhänge in der digitalen Datenübertragung empfehle ich zusätzlich noch folgende Links, denn das im Internet versammelte, von Wissenschaftlern anerkannte Wissen kann man schlecht in einen eigenen Aufsatz packen.
Die Links stellen eine auf die Schnelle gefundene Auswahl dar. Es gibt sicherlich noch viele andere, vielleicht auch noch bessere und /oder noch besser passende.
Hier ein sehr gutes Seminar. Leicht erhöhte Downloadzeit des PDF beachten.
Introduction to Jitter Techniques for High Speed Serial Technologies
http://formation.in2p3.fr/Numerique16/S ... 20FY16.pdf
Etwas grenzwertig aber trotzdem viel Wahres drin.
„The Sound of network switches“.
https://www.youtube.com/watch?v=BbRF8z8dQFU
Auch im bekannten Netzwerkkarten-Chip I210 geht es thematisch um Jitter
Bitte bei Interesse nach diesem Wort im PDF suchen.
https://www.mouser.com/datasheet/2/612/ ... 257785.pdf
Agilent 81250 ParBERT Jitter Injection and Analysis Capabilities
https://fenix.tecnico.ulisboa.pt/downlo ... 5/AG03.pdf
Jitter Specifications Made Easy:
A Heuristic Discussion of Fibre Channel and Gigabit Ethernet Methods
https://pdfserv.maximintegrated.com/en/an/AN377.pdf
Viele Grüße,
Horst