The Sound of Ethernet
Hallo zusammen,
obwohl ich zwar kein Vertreter der Ethernet-Jitter-Klang-Theorie bin hier einen Tip an die Vertreter dieser Theorie:
Man sollte doch mal den gesamten Weg der Daten von dem Netzwerkinterface über den Systembus in den Speicher von dort über Systembus zum USB Controller und von dort über asynchrone USB Kommunikation zum DAC betrachten und erläutern, wie sich Ethernet Jitter beim DAC bemerkbar macht.
Damit wäre vielen geholfen und wenn dies schlüssig dargelegt werden kann, dann macht es Sinn hier weiter zu machen.
Beste Grüsse,
Eric
obwohl ich zwar kein Vertreter der Ethernet-Jitter-Klang-Theorie bin hier einen Tip an die Vertreter dieser Theorie:
Man sollte doch mal den gesamten Weg der Daten von dem Netzwerkinterface über den Systembus in den Speicher von dort über Systembus zum USB Controller und von dort über asynchrone USB Kommunikation zum DAC betrachten und erläutern, wie sich Ethernet Jitter beim DAC bemerkbar macht.
Damit wäre vielen geholfen und wenn dies schlüssig dargelegt werden kann, dann macht es Sinn hier weiter zu machen.
Beste Grüsse,
Eric
-
- Aktiver Hörer
- Beiträge: 9165
- Registriert: 14.06.2009, 15:45
Hallo Frank,Dilbert hat geschrieben: ↑15.06.2022, 23:21OK, PLL sind anscheinend Dein Hobby, also jetzt mal Butter bei die Fische, wie sieht den jetzt Deine Theorie über den Einfluß der PLL's auf die Füllung des Puffers und dann auch auf den Klang aus? Wenn Du so viel mehr Wissen hast, als die didaktische Aufbereitung zu dem Thema zu bieten hat, dann wäre es schön, wenn Du uns teilhaben läßt...
wie wäre es, wenn du aus innerem Antrieb selbst mal recherchierst, statt von mir zu erwarten, in 2 Minuten lesbare unwiderlegbare Fakten zu präsentieren, für die ich mehr als 2 Stunden überzeugende Links zusammentragen muss?
Es ist bekannt, dass auf ein Seminar geschickte Mitarbeiter die Seminarinhalte schnell vergessen haben, während die aus Eigeninteresse teilnehmenden Kollegen die Inhalte verinnerlicht haben.
In 8 Stunden geht mein Zug zu dem von mir aus der Entfernung organisierten Jahrgangstreffen anlässlich unseres vor 50 Jahren bestandenen Abiturs. Ich hoffe, dass ich auf der Zugfahrt Internetzugang habe, dann werde ich mich bemühen, deine Fragen mit Links zu beantworten, die vorzugsweise aus diesem Forum stammen, also von dir bereits hätten wahrgenommen worden sein können, Aufmerksamkeit vorausgesetzt.
IIRC war ein solcher entscheidender Link in diesem Thread weiter oben, auf Texas Instruments
----------------
Ich habe mir jetzt zu später Stunde noch die Mühe gemacht, den Link zu suchen, damit man mir nicht nachsagt, ich wäre nicht in der Sache bemüht: viewtopic.php?p=219810#p219810 Eric hat dort auf ein Texas Tutorial verwiesen, und das solltest du mal als glaubwürdig anerkennen, weil vom Hersteller selbst: https://training.ti.com/what-is-clock-and-data-recovery Und schon wieder PLL...
Wikipedia über Netzwerkkommunikation steht jedermann zur Verfügung, ist dadurch gewissermaßen als Allgemeinwissen zu betrachten. Da brauche ich mich also nicht weiter zu äußern. Finde es dort selbst heraus. Das scheint mir besser als wenn ich es dir erklären muss und du es mir nicht glaubst. Denn ich habe es nicht selbst in der Schule gelernt, damals gab es sowas noch nicht.
Grüße
Hans-Martin
Hi, Frank,Dilbert hat geschrieben: ↑15.06.2022, 19:32 Hallo
......
Und zum Jitter innerhalb des DACs: Das man hochpräzise Clocks im Studio verwendet hat meines Erachtens nicht mit dem Klang der einzelnen digitalen Komponente zu tun, sondern mit der notwendigen Synchronisation vieler digitalen Komponeten. ......
Grüße
Frank
genauso ist es.
Bei der Wiedergabe ist das Problem halt, dass jedes Gerät als Master fungiert; der CD-Player gibt denTakt vor, der DAC taktet nochmals.
An meinem DAC hängt der CD-T als Slave dran, wird vom DAC gesteuert.
Gruß
Günther
Hallo zusammen,
Seine Erkenntnisse hat er in einem Whitepaper zusammengefasst: https://cdn.shopify.com/s/files/1/0660/ ... 1583429386
Viele Grüße
Henning
John Swenson hat vor der Entwicklung des Etherregen sich nach seiner Aussage wohl sehr intensiv mit der Thematik beschäftigt und umfangreiche Messungen gemacht.
Seine Erkenntnisse hat er in einem Whitepaper zusammengefasst: https://cdn.shopify.com/s/files/1/0660/ ... 1583429386
Viele Grüße
Henning
Hallo zusammen,
Bitte meinen Posts nicht als Provokation verstehen, sondern ich bin hier wirklich interessiert, dieses Thema aufzulösen.
Falls jemand nachvollziehen will wie denn die Mechanismen zum Einsortieren von Ethernet Daten in das Regal funktioniert, hier ein Artikel, der im ersten Abschnitt ein sehr gutes erstes Verständnis vermittelt. (Man möge mir nachsehen, das ich auf externe Artikel verweise. Aber ich glaube nicht, das eine eigene Beschreibung hiervon einen Mehrwert bieten würde)
https://www.linkedin.com/pulse/modern-h ... velegrakis
Falls diesen Artikel jemand aus der Jitter Fraktion lesen sollte, oder vielleicht das schon alles bekannt ist, dann sollte doch hieran am besten erläutert werden, wie Ethernet Jitter sich auswirken können oder die Theorie von rostigen Nägeln darlegen.
Kurze Zusammenfassung: Signal wird mit Hilfe von PLL interpretiert (nicht Bestandteil dieses Artikels) und dann als Daten in den Memory des Netzwerkinterface (mit eigener Clock bei einer Netzwerkkarte) geschrieben und wenn fertig über den IO Bus mit eigener Taktung (mit Clock vom Hauptboard) abgeholt und dann in den Hauptspeicher geschrieben.
Von da würde es dann weiter gehen, was dann ja in einer weiteren Betrachtung passieren kann.
Beste Grüße,
Eric
Bitte meinen Posts nicht als Provokation verstehen, sondern ich bin hier wirklich interessiert, dieses Thema aufzulösen.
Falls jemand nachvollziehen will wie denn die Mechanismen zum Einsortieren von Ethernet Daten in das Regal funktioniert, hier ein Artikel, der im ersten Abschnitt ein sehr gutes erstes Verständnis vermittelt. (Man möge mir nachsehen, das ich auf externe Artikel verweise. Aber ich glaube nicht, das eine eigene Beschreibung hiervon einen Mehrwert bieten würde)
https://www.linkedin.com/pulse/modern-h ... velegrakis
Falls diesen Artikel jemand aus der Jitter Fraktion lesen sollte, oder vielleicht das schon alles bekannt ist, dann sollte doch hieran am besten erläutert werden, wie Ethernet Jitter sich auswirken können oder die Theorie von rostigen Nägeln darlegen.
Kurze Zusammenfassung: Signal wird mit Hilfe von PLL interpretiert (nicht Bestandteil dieses Artikels) und dann als Daten in den Memory des Netzwerkinterface (mit eigener Clock bei einer Netzwerkkarte) geschrieben und wenn fertig über den IO Bus mit eigener Taktung (mit Clock vom Hauptboard) abgeholt und dann in den Hauptspeicher geschrieben.
Von da würde es dann weiter gehen, was dann ja in einer weiteren Betrachtung passieren kann.
Beste Grüße,
Eric
-
- Aktiver Hörer
- Beiträge: 575
- Registriert: 24.11.2019, 11:48
- Wohnort: Zürich
Hallo EricMilhouse hat geschrieben: ↑15.06.2022, 23:54
Man sollte doch mal den gesamten Weg der Daten von dem Netzwerkinterface über den Systembus in den Speicher von dort über Systembus zum USB Controller und von dort über asynchrone USB Kommunikation zum DAC betrachten und erläutern, wie sich Ethernet Jitter beim DAC bemerkbar macht.
ja genau.
Den Weg den Du oben beschrieben hast ist eine Möglichkeit. Genaus so ist es bei mir.
Es gibt noch andere, Audio over IP (DANTE etc. AES67), AES/EBU SPDIF etc.
Beim Weg über USB asynchron zum DAC ist Ethernet weit weg, also sehr viel dazwischen besonders Prozessor, Operatingsystem, Software RAM, Disk etc. etc. Sehr abhängig von der konkreten Realisierung, also welche Geräte man hat.
USB asynchron zum DAC: In dieser Konstellation ersuche ich um Erklärung wieso Ethernet eine Rolle spielt für die Audioqualität. Das Höchste was ich mir vorstellen kann, dass der Datenstrom abreisst (Streaming oder externens NAS via Ethernet) und dann ist es einfach einen Moment lang still (Ethernetkabel ausziehen als Test, es dudel noch eien Moment weiter bis der Puffer leer ist
![Smile :)](./images/smilies/icon_smile.gif)
Gruss
Peter
-
- Aktiver Hörer
- Beiträge: 1544
- Registriert: 03.07.2012, 10:56
- Wohnort: Leipzig
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,
Ich verstehe selbstverständlich den Ansatz, Dinge isoliert und differenziert zu betrachten, allerdings ist mir nicht ganz klar, wieso man gerade hier so strikt trennen muss - in meinen Augen ist der Weg, wie die Daten letztendlich zum DAC kommen, nämlich beinahe irrelevant und zwar in der Hinsicht, dass alle bekannten und gerade in diesem Forum hier dutzendfach getesteten, verbesserten, kombinierten etc.... Übertragunsarten sich im Ergebnis bestenfalls graduell niederschlagen, jedoch immer und überall hörbare Beeinflussungen zu erkennen sind, die in ihren letztendlichen klanglichen Auswirkungen absolut vergleichbar, wenn nicht gar identisch sind.
Es macht bestenfalls im Ausmaß der Klangbeeinflussung einen Unterschied, ob ich per WLAN, LWL oder USB oder intern oder wie auch immer zuspiele - die jeweils hörbaren Veränderungen (ich verstehe sie allesamt als mal mehr, mal weniger durchschlagende Fehler) sind in Art und Weise immer ähnlich - was für mich nur den (altbekannten) Schluss zulässt, dass unabhängig des Zuspielweges das eigentliche Problem im DAC zum Tragen kommt und man bestenfalls versuchen kann, ihm die Arbeit so leicht wie möglich zu machen, indem man bei der Zuspielung möglichst wenige Fehler macht, sprich bemüht ist, so wenige offensichtliche Störeinflüsse wie möglich zu generieren/ weiterzuleiten.
Soweit, so gut - und klar kann ich mittels isolierter Betrachtung auf nur eine Zuspielart (Ethernet) und Größe (Jitter) versuchen, hier durch Messungen vorrangig mittels Ausschlussverfahren die These zu zu belegen, dass es eben nicht der Jitter im Netzwerk ist, der Relevanz hat (was für praktisch jeden IT-Techniker eh vollkommen außer Frage steht) und wenn das das Ziel dieses Threads hier ist, so ist das zu akzeptieren.
In Anbetracht dessen, was gerade hier im Forum in den letzten Jahren an hörbaren Einflussgrößen und Wegen, damit umzugehen, herausgefunden wurde, fände ich wie auch immer ausgehende Messungen in diesem isolierten Fall jedoch von nicht gerade überragender praktischer Relevanz, sondern sehe sie dies bestenfalls als relativ kleines Puzzlestück, was die unzähligen gehörten Erfahrungen weder zu erklären noch obsolet zu machen in der Lage ist, weswegen eine zumindest etwas erweiterte Diskussion zu dieser Thematik in meinen Augen durchaus Sinn ergibt.
VG,
Thomas
Hallo Henning,HenSch hat geschrieben: ↑16.06.2022, 09:11 Hallo zusammen,
John Swenson hat vor der Entwicklung des Etherregen sich nach seiner Aussage wohl sehr intensiv mit der Thematik beschäftigt und umfangreiche Messungen gemacht.
Seine Erkenntnisse hat er in einem Whitepaper zusammengefasst: https://cdn.shopify.com/s/files/1/0660/ ... 1583429386
Viele Grüße
Henning
vielen Dank hierfür!! - hatte ich fast vergessen, das Swenson dieses Whitepaper gemacht hat.
Swenson macht ja Rauschen im Massesystem (Ground-Plane Noise) für die Klangunterschiede verantwortlich.
Das deckt sich auch mit meiner These, da ja die Störungen im Gleichtakt über die Kondensatoren der Bob Smith Terminierung in das Massesystem kommen.
Swenson erläutert aber in seinen Ausführungen nicht, wie denn die das Masse-Rauschen von einem System auf das andere übergehen.
Das erfolgt m.E. genau da wo ich ansetze - im Gleichtakt des Ethernet Signals (lassen wir mal die Masseverbindung einer Schirmung Aussen vor).
Letztendlich besteht über das Ethernet Kabel mit seinen auf beiden Seiten bestehenden Bob Smith Terminierungen ein HF Masse Bezug von Switch zu Endpunkt. (der auch durch einen Isolator nicht aufgehoben wird).
Daher auch meine These, das nicht der Jitter im Signal, sondern höchstens die verminderten Störungen im Gleichtakt bei einer besseren Clock verantwortlich sein können. Dieses hat sich allerdings bei dem G-Switch nicht bewahrheitet. Ich habe einen Meraki mit und ohne Clock Upgrade im Zulauf, der mir freundlicherweise von Martin / Audiophon zur Verfügung gestellt wird - hier schon mal vielen Danke an Martin
![Cheers :cheers:](./images/smilies/icon_cheers.gif)
Eventuell muss ich meinen Messaufbau nochmal überdenken. Ich messe ja die Gleichtaktstörungen gegen die Masse des Senders. Eigentlich müsste ich gegen die des Empfängers messen (da habe ich allerdings dann das Masserauschen des Empfängers).
Hallo Thomas,music is my escape hat geschrieben: ↑16.06.2022, 10:04 Soweit, so gut - und klar kann ich mittels isolierter Betrachtung auf nur eine Zuspielart (Ethernet) und Größe (Jitter) versuchen, hier durch Messungen vorrangig mittels Ausschlussverfahren die These zu zu belegen, dass es eben nicht der Jitter im Netzwerk ist, der Relevanz hat (was für praktisch jeden IT-Techniker eh vollkommen außer Frage steht) und wenn das das Ziel dieses Threads hier ist, so ist das zu akzeptieren.
du hast ganz recht - in diesem Thread geht es um die isolierte Betrachtung, was im Bereich Ethernet passiert (jedoch nicht darum irgend eine vorgefasste MEinung zu bestätigen).
Das Bedeutet nicht, das diese für das Gesamte Forum jetzt zutrifft.
Es gibt Threads, die sich mit einem Einzelthema beschäftigen -z.B. Feinsicherung. Dazu sind Threads ad.
Ich grätsche da auch nicht dauern rein und erkläre wie nichtig dieses Thema ist, total unbedeutend und man solle sich doch bitte mal um die Stromverteiler an der Stassenecke kümmern.
In diesem Sinne kannst Du ja gerne andere Thread aufmachen, die galaktischer das Thema abhandeln.
Aber der Titel des Threads und Inhalt ist nun mal "Sound of Ethernet".
Beste Grüsse,
Eric
Guten Morgen,
wenn ich das von Henning verlinkte white paper richtig verstanden habe, wird ein Mechanismus beschrieben der über die Bezugserde ("ground plane") wirkt. Nicht der Jitter der Daten oder Signale selbst wäre relevant, sondern nur das -- laut Autor -- auch auf der Bezugserde anliegende Phasenrauschen der verwendeten Clocks (Sender und Empfänger überlagern sich). Ein solches Rauschen würde dann wiederum Einfluss auf die Clockstabilität im DAC selbst nehmen, was wiederum neuen Jitter erzeugt.
Ob die im white paper gemachte Aussage, dass sich das Phasenrauschen der Clocks auch so in der Bezugserde findet, korrekt ist, kann ich leider nicht bewerten. Kann jemand mit mehr Hardware-Nähe also ich bewerten, ob das Sinn macht? Dass Störungen (letztlich spricht das paper nur von Störungen, die leitungsgebunden in den DAC dringen) Auswirkungen im DAC und insbesondere die DAC-Clock haben, kann ich mir sehr gut vorstellen.
Im Kern ist die Aussage: Die Sender/Empfanger-Clocks haben Phasenrauschen, das über die Bezugserde die DAC-Clock beeinflusst. Der Jitter beim Datentransfer ist wurscht.
Letztlich sind die Lösungen dafür aber wieder die üblichen Verdächtigen: leitungsgebundene Störungen verringern (z.B. über Filter) und eine sauber Versorgung der DAC-Clock. Einzig problematisch -- falls sich wirklich das Phasenrauschen auf der Bezugserde wiederfindet -- ist das niederfrequente Spektrum desselben. Soweit ich weiß wirken übliche Filter vor allem im Bereich und nicht im NF-Bereich.
Grüße,
Andree
wenn ich das von Henning verlinkte white paper richtig verstanden habe, wird ein Mechanismus beschrieben der über die Bezugserde ("ground plane") wirkt. Nicht der Jitter der Daten oder Signale selbst wäre relevant, sondern nur das -- laut Autor -- auch auf der Bezugserde anliegende Phasenrauschen der verwendeten Clocks (Sender und Empfänger überlagern sich). Ein solches Rauschen würde dann wiederum Einfluss auf die Clockstabilität im DAC selbst nehmen, was wiederum neuen Jitter erzeugt.
Ob die im white paper gemachte Aussage, dass sich das Phasenrauschen der Clocks auch so in der Bezugserde findet, korrekt ist, kann ich leider nicht bewerten. Kann jemand mit mehr Hardware-Nähe also ich bewerten, ob das Sinn macht? Dass Störungen (letztlich spricht das paper nur von Störungen, die leitungsgebunden in den DAC dringen) Auswirkungen im DAC und insbesondere die DAC-Clock haben, kann ich mir sehr gut vorstellen.
Im Kern ist die Aussage: Die Sender/Empfanger-Clocks haben Phasenrauschen, das über die Bezugserde die DAC-Clock beeinflusst. Der Jitter beim Datentransfer ist wurscht.
Letztlich sind die Lösungen dafür aber wieder die üblichen Verdächtigen: leitungsgebundene Störungen verringern (z.B. über Filter) und eine sauber Versorgung der DAC-Clock. Einzig problematisch -- falls sich wirklich das Phasenrauschen auf der Bezugserde wiederfindet -- ist das niederfrequente Spektrum desselben. Soweit ich weiß wirken übliche Filter vor allem im Bereich und nicht im NF-Bereich.
Grüße,
Andree
Guten Morgen,
ich habe einen Beitrag aus dem Jahr 2020 gefunden, der eine ähnliche Aussage "Der Jitter beim Datentransfer ist wurscht" schon damals ausgesprochen hat:
viewtopic.php?f=14&t=11124&p=201767#p201767
Gruesse
Stanislaw
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
Hallo Horst,
Genau dieses Jitter Budge erkläre doch an dem von mir aufgezeigten Weg der Daten im Streamer / Pc mit Zwischenspeichern und Transport mit ganz anderer Taktung nach Empfang der Daten.
Solange du bei einer Übertragungsform bleibst ist das Jitter Budge mit verständlich, aber nicht, wenn die Daten zwischengespeichert werden und mit ganz anderer Taktung und auch anderer analoger Übertragung und Protokoll weitergesendet werden.
Beste Grüße,
Eric
Genau dieses Jitter Budge erkläre doch an dem von mir aufgezeigten Weg der Daten im Streamer / Pc mit Zwischenspeichern und Transport mit ganz anderer Taktung nach Empfang der Daten.
Solange du bei einer Übertragungsform bleibst ist das Jitter Budge mit verständlich, aber nicht, wenn die Daten zwischengespeichert werden und mit ganz anderer Taktung und auch anderer analoger Übertragung und Protokoll weitergesendet werden.
Beste Grüße,
Eric
-
- Aktiver Hörer
- Beiträge: 1544
- Registriert: 03.07.2012, 10:56
- Wohnort: Leipzig
Hallo Eric,Milhouse hat geschrieben: ↑16.06.2022, 12:25 Hallo Horst,
Genau dieses Jitter Budge erkläre doch an dem von mir aufgezeigten Weg der Daten im Streamer / Pc mit Zwischenspeichern und Transport mit ganz anderer Taktung nach Empfang der Daten.
Solange du bei einer Übertragungsform bleibst ist das Jitter Budge mit verständlich, aber nicht, wenn die Daten zwischengespeichert werden und mit ganz anderer Taktung und auch anderer analoger Übertragung und Protokoll weitergesendet werden.
dass dein Histogramm nach einer Zwischenspeicherung, neuem Auslesen und dann weiterverarbeiten wieder schmal wird, ist für mich vorstellbar.
Aber ich denke das nützt nichts.
Mit Jitter Budget im vorhandenen Home Setup wollte ich etwas anderes sagen. Nimm eine miserable, klirrige, verjitterte Aufnahme die auf dem NAS liegt, dazu dann ein in dem Moment on the fly genutzer suboptimaler Ethernet Weg, dann noch ein wenig Jitter im Streamer, im DDC und im DAC, vielleicht noch kombiniert mit einer minderwertigen klirrigen (ist nicht Jitter) Endstufe, dann willst du gar nicht weiterhören. Das addiert sich für das Ohr / Gehirn alles auf.
Viele Grüße,
Horst