10-MHz-Masterclocks in der Diskussion

h0e
Administrator
Beiträge: 3864
Registriert: 11.11.2013, 09:40
Wohnort: München

Beitrag von h0e »

higginsd hat geschrieben: Kernaussage: "Audio devices must own the audio clock."

RAAT schickt nur Daten, das Clocking liegt vollständig in der Hoheit des empfangenden Devices.
Hallo Dirk,

leider lässt die Aussage außer Acht, dass auch Datenübertragung geclockt werden muss. Dafür gibt es extra die Referenzclockeingänge z.B. am Etherregen. Ein sauberes Clocking der Datenpakete (nicht nur für Roon, denn auch die anderen IP Verbindungen enthalten i.d.Regel kein Clocksignal) z.B. mit Unterstützung einer Ref10 sind in der Regel deutlich hörbar.

Grüsse Jürgen
Bild
Markush
Aktiver Hörer
Beiträge: 362
Registriert: 02.08.2021, 11:44

Beitrag von Markush »

Hallo Jörg,

oh sorry hatte ich gar nicht am Schirm.
Ist dann aber spannend, dass deswegen wahrscheinlich der preislich attraktive NS dem AD (der ja auf Sinus basiert) beim Test mit dem ER natürlich mit Abstand aber doch recht nahe kommt.
Gibt es auf Basis des Rechtecksignals noch andere Masterclocks die hier in Kombination mit dem ER sich besonders gut eignen zB von Cybershaft etc?

Liebe Grüße
Markus
Bild
higginsd
Aktiver Hörer
Beiträge: 290
Registriert: 21.10.2021, 13:32
Wohnort: Aachen

Beitrag von higginsd »

Hallo Jürgen!

Jetzt hat das System meine mühevoll und ausführlich erstellte Antwort verschluckt und ich habe keine Lust, sie erneut zu verfassen.

Ganz kurz: ich bin mit Dir nicht einer Meinung. Jitter im LAN hat keinerlei Einfluss auf die Korrektheit der gesendeten/empfangenen Daten, wenn man die TimeDomain, also zeitliche Abhängigkeiten, nicht beachten muss.

Insofern ist RAAT hier sicherlich eine sehr gute Lösung, setzt aber den Einsatz von Roon voraus.

Grüße
Dirk
Bild
h0e
Administrator
Beiträge: 3864
Registriert: 11.11.2013, 09:40
Wohnort: München

Beitrag von h0e »

Hallo Dirk,

Leider ist das eine idealisierte Vorstellung. Sie Dir bitte Dir Threads zum Clocktuning an. Egal ob Linn Geräte an der Netzwerkclock, egal ob Switches oder Mediaconverter, immer ist das saubere Signal gut hörbar, obwohl wir von Datenpaketen reden. Dabei ist es egal ob RAAT oder auch UPnP. Irgendwo gab es dazu auch messtechnische Ansätze dazu. Ich habe leider den Thread nicht gefunden. Das ist auch der Grund, warum eine 10MHz Clock an einem Etherregen einen deutlichen Unterschied machen kann. Das haben hier reichlich Foristen unabhängig voneinander berichtet.

Grüsse Jürgen
Bild
higginsd
Aktiver Hörer
Beiträge: 290
Registriert: 21.10.2021, 13:32
Wohnort: Aachen

Beitrag von higginsd »

Hallo Jürgen!

Sorry, aber da bin ich raus. Das ist technisch unmöglich. Wenn das so wäre, müsste ja der Inhalt der Daten während der Übertragung verändert worden sein.

Und nochmal: ich rede von der reinen Datenübertragung ohne Betrachtung der TimeDomain. Denn wenn die ins Spiel kommt, ist es klar, da TCP/IP Pakete in willkürlicher Reihenfolge ausliefert. Wenn ich also zeitkritisch beispielsweise aus den Daten von 3 Paketen ein Musiksignal DA konvertieren muss und mir in der Mitte das Paket fehlt und ich dann interpolieren muss - ja dann erzeuge ich "Jitter" oder "Schmutz" im Stream.

Aber wenn die TimeDomain keine Rolle spielt, kommt hinten EXAKT das an, was vorne abgeschickt wurde. Sonst würde auf diesem Planeten nicht eine einzige HTTPS-Connection laufen oder ständig gestört sein. Denn in einem verschlüsselten Datenstream reicht 1 einziger Bitkipper auf - von mir aus - Megabytes - und das entschlüsselte Ergebnis wäre Garbage.

Wo also soll "Netzwerk-Jitter" Einfluss haben und einen Unterschied zwischen den Daten, die der Musikserver abschickt und den Daten, die der DAC empfängt, einbauen, um das Musiksignal zu verfälschen? Vorausgesetzt der DAC hat die Hoheit darüber, die empfangenen Daten mit seinem Clocking wieder zeitrichtig abzuspielen.

Bei UPnP ist das aber genau NICHT so, denn das Clocking geht mit über das LAN. Das mag Jitter erzeugen können. RAAT ist aber wie gesagt "clockless", es ist Aufgabe des Empfängers mit seiner Clock die empfangenen Daten wieder in die korrekte Relation zur Zeit zu setzen.

Ich selber höre Unterschiede zwischen einem normalen SPDif-Signal und einem re-clockten SPDif-Signal, auch Unterschiede, wenn der Re-Clocker zusätzlich mit einer Masterclock getaktet wird (allerdings nur marginal). Aber beim Re-Clocking ist vorher irgendwo entstandener Jitter aus dem Signal vor dem Versenden entfernt bzw. korrigiert worden. Er war also tatsächlich da.

Leider ist das Versenden über SPDif dann auch wieder nicht frei von der TimeDomain, weshalb mir eine SPDif-Verbindung zwischen meinem Re-Clocker und meinem DAC leider letztlich auch nicht ausreichend erscheint. Aber eine andere Möglichkeit bietet mein DAC leider nicht, besser wäre, wenn er nur die Daten empfangen würde und diese dann mit seiner Clock - unterstützt von einer Masterclock - wieder sauber auf die zetliche Schiene nageln würde.

Aber vielleicht lassen wir die Diskussion besser, ich bin seit über 35 Jahren in der IT-Branche und zu sehr Techie, um da mit Dir auf einen Nenner zu kommen. :cheers:

Viele Grüße
Dirk
Bild
StreamFidelity
Aktiver Händler
Beiträge: 1599
Registriert: 24.09.2017, 14:50
Wohnort: Hansestadt Rostock
Kontaktdaten:

Beitrag von StreamFidelity »

Hallo Dirk,
higginsd hat geschrieben: 12.11.2021, 12:50Sorry, aber da bin ich raus. Das ist technisch unmöglich. Wenn das so wäre, müsste ja der Inhalt der Daten während der Übertragung verändert worden sein.
Meine Frage nach Messprotokollen zu RAAT hatte nicht den Hintergrund eine bitidentische Übertragung in Frage zu stellen. Vielmehr ist es so, dass ich Roon gerne benutze. Und trotz des RAAT-Protokolls höre ich erstaunliche Verbesserungen je besser der digitale Signlaweg reclocked wird. Das ist ja auch der Sinn des Threads hier Erfahrungen auszutauschen. Egal ob USB (sollte technisch bei asynchronen Modus ja auch keine Rolle spielen) oder Ethernet, eine hochwertige Clock brachte bei mir immer etwas.
higginsd hat geschrieben: 12.11.2021, 12:50Aber vielleicht lassen wir die Diskussion besser, ich bin seit über 35 Jahren in der IT-Branche und zu sehr Techie, um da mit Dir auf einen Nenner zu kommen.
Diese Grundsatzdiskussionen habe ich ehrlich gesagt auch satt. Vielleicht hindert Dich genau Dein technischer Hintergrund neue Erfahrungen zu sammeln. Denn was nicht sein kann darf nicht sein, oder? Probiere es doch einfach mal aus oder besuche Forenten, die das haben. :wink:

Grüße Gabriel
Bild
Audiophon
Aktiver Hörer
Beiträge: 835
Registriert: 29.01.2020, 16:50
Wohnort: Frankfurt a.M.

Beitrag von Audiophon »

higginsd hat geschrieben: 12.11.2021, 12:50
Und nochmal: ich rede von der reinen Datenübertragung ohne Betrachtung der TimeDomain. Denn wenn die ins Spiel kommt, ist es klar, da TCP/IP Pakete in willkürlicher Reihenfolge ausliefert. Wenn ich also zeitkritisch beispielsweise aus den Daten von 3 Paketen ein Musiksignal DA konvertieren muss und mir in der Mitte das Paket fehlt und ich dann interpolieren muss - ja dann erzeuge ich "Jitter" oder "Schmutz" im Stream.

Aber wenn die TimeDomain keine Rolle spielt, kommt hinten EXAKT das an, was vorne abgeschickt wurde. Sonst würde auf diesem Planeten nicht eine einzige HTTPS-Connection laufen oder ständig gestört sein. Denn in einem verschlüsselten Datenstream reicht 1 einziger Bitkipper auf - von mir aus - Megabytes - und das entschlüsselte Ergebnis wäre Garbage.

Wo also soll "Netzwerk-Jitter" Einfluss haben und einen Unterschied zwischen den Daten, die der Musikserver abschickt und den Daten, die der DAC empfängt, einbauen, um das Musiksignal zu verfälschen? Vorausgesetzt der DAC hat die Hoheit darüber, die empfangenen Daten mit seinem Clocking wieder zeitrichtig abzuspielen.
Hallo Dirk,

ich finde diese Diskussion rein auf der theoretischen und technischen Ebene wiederum sehr interessant! Für mich gerne mehr davon... vielleicht hast Du mir ja einen Link mit auch für Laien verständlichen Erklärungen :wink:

Viele Grüße
Martin
Bild
higginsd
Aktiver Hörer
Beiträge: 290
Registriert: 21.10.2021, 13:32
Wohnort: Aachen

Beitrag von higginsd »

Hallo!

Eigentlich möchte ich das Thema hier nicht breittreten, im Streit zu vermeiden.

Sagen wir es ganz kurz: wenn ich eine Musikdatei, ein FLAC-File, von meinem MacBook über LAN auf meinen Roon-Server kopiere: hat die dann anschließend auf dem Server liegend mehr Jitter "in sich drin", als auf meinem MacBook?

Falls ja, hat "Jitter im LAN" einen Einfluss auf das, was RAAT macht. Falls nein, brauche ich für RAAT keine Netzwerk-Clock. RAAT kopiert ein Audiofile bitgenau zum Empfänger in einen Buffer. So, als hätte der Empfänger eine Festplatte, wo sie gespeichert wird.

Erst der Empfänger ist dann dafür verantwortlich, diese Datei oder Bit-/Bytefolge wieder zu lesen und mit einem Taktsignal die zeitliche Relation zwischen Bitfolge aus der Datei und der ursprünglichen Bitfolge bei der Aufzeichnung der Datei herzustellen. Beide Taktraten sollten möglichst genau und identisch sein, sonst stimmt die DA-Wandlung nicht mit der AD-Wandlung überein - und man erzeugt Jitter. Minimalste zeitliche Abweichungen gegenüber der Quelle in dem aus den Bits generierten analogen Audiosignal, weil Bits zu früh oder zu spät in die "Berechnung" des analogen Signals einfliessen. Und das klingt halt sch..., wenn die Abweichung zu groß wird, harmonische Obertöne in den Bereich der disharmonischen Obertöne verschiebt usw. usw. - und unser Ohr/Hirn das mitbekommt.

Mag sein, daß ich viele Dinge stark vereinfacht habe und nicht korrekt beschreibe. Aber ich bin ein einfach strukturiertes Kerlchen, nur kann mir niemand glaubhaft machen, daß Filecopies im LAN durch Jitter verändert werden. Dann wäre ich ständig "in Gottes Hand" und wahrscheinlich längst arbeitslos.

Das soll es aber von meiner Seite zum Thema gewesen sein.

Viele Grüße
Dirk
Bild
StreamFidelity
Aktiver Händler
Beiträge: 1599
Registriert: 24.09.2017, 14:50
Wohnort: Hansestadt Rostock
Kontaktdaten:

Beitrag von StreamFidelity »

Hallo zusammen,

ich habe eine andere Sicht auf den Jitter. Als erstes die Definition gemäß Wikipedia:
Als Jitter (engl. für ‚Fluktuation‘ oder ‚Schwankung‘) bezeichnet man das zeitliche Taktzittern bei der Übertragung von Digitalsignalen, eine leichte Genauigkeitsschwankung im Übertragungstakt (engl.: Clock).
Dirk argumentiert mit dem Puffer. Ist der Puffer groß genug gleicht sich das wieder aus, da der DAC (oder die Masterclock) neu reclocked.

Nun folgen meine Thesen.

Das Problem ist, dass die Musik zeitkritisch ist. Die Daten müssen irgendwann aus dem Speicher, sonst gehen Datenpakete verloren und man hört dann zum Beispiel die oft geschilderten Knackser. Also Schallplatte mal digital. :D

Hier kommt eine für mich weitere wichtige Komponente ins Spiel: die Latenzen. Die relevanten Latenzen sind jedoch nicht die Audiolatenzen, sondern die Latenzen auf OS-/Prozessebene!

Störende Latenzen liegen im Datenstrom und in der Datenverarbeitung begründet. Beim Rendern von Audiosignalen (z. B. von Flac in PCM oder DSD) und der Übertragung dieser Daten entstehen Latenzen. Sie ergeben sich aus der von der Soft- und Hardware benötigten Zeit, die Daten zu verarbeiten. Bei der Datenübertragung spielen zudem der Sample-Puffer (engl. Buffer) eine Rolle, die bei Audiokarten üblicherweise im Bereich zwischen 64 und 512 Samples liegen, um ein Abreißen des Datenstroms zu verhindern. Und natürlich muss auch das Übertragungsprotokoll RAAT von der CPU codiert werden.

Während die Latenz eine feste Zeit zwischen Aktion und Reaktion definiert, beschreibt Jitter die Schwankungen innerhalb dieser Zeit. Je kürzer ich die Latenzen halte, desto geringer können die Taktschwankungen ausfallen. Und genau das sind meine Erfahrungen. Egal wo ich die Latenzen optimiert habe (USB-Puffer, Ethernet-Puffer, latenzminimierte Solarflare NIC, etc.) gab es eine Klangverbesserung.

Es gibt also einen Zusammenhang zwischen Jitter und Latenzen.

Es bleibt noch die Frage offen, warum das Reclocking etwas bringt, obwohl der DAC die Signale aus dem Puffer neu taktet. Ich kann hier nur vermuten. Wenn die Zuspielung möglichst taktgenau, jitterminimiert mit geringsten Latenzen erfolgt hat die DAC-Clock einfach weniger Arbeit. Der DAC-Puffer wird nicht übermäßig voll und kann zeitnah abgearbeitet werden. Aufgrund der hohen Taktgenauigkeit sind die (kleineren) Datenpakete in der richtigen Reihenfolge sofort verfügbar.

Wie auch immer. Es muss nicht richtig sein, was ich schreibe. Nur weil etwas (noch nicht) wissenschaftlich fundiert erklärt werden kann, muss das Gehörte nicht falsch sein. Dieses Problem haben wir bei Kabel(klang) ja auch. :wink:

Grüße Gabriel
Bild
Markush
Aktiver Hörer
Beiträge: 362
Registriert: 02.08.2021, 11:44

Beitrag von Markush »

Hallo zusammen,

zu dieser Thematik Jitter und Einfluss / Störungen der digitalen Übertragung denk ich auch sehr spannend sind die Ausführungen hier: https://audiophilestyle.com/forums/topi ... nt=1064795

Liebe Grüße
Markus
Bild
chriss0212

Beitrag von chriss0212 »

Hallo Gabriel
Es gibt also einen Zusammenhang zwischen Jitter und Latenzen.
Mmmhhh… FIR Filter, mit denen Du selber hörst, haben eine sehr große Latenz… und nu?

Es gibt hier im Forum einige, die für sich als den Weg der Wege herausgefunden haben: je geringer der CPU Tackt um so besser… und nu?

Ich finde Du pauschalisierst hier deinen extrem Processorhungrigen Weg über DSD, der ja auch eher umstritten ist.

Grüße

Christian
chriss0212

Beitrag von chriss0212 »

Hallo Gabriel

Das soll übrigens nicht ablehnend oder aggressiv rüber kommen! Hab es noch mal gelesen und kann so verstanden werden :cheers:

Nur: Wenn Deine These stimmt… was hören denn dann die Anderen?

Viele Grüße

Christian
Hans-Martin
Aktiver Hörer
Beiträge: 9118
Registriert: 14.06.2009, 15:45

Beitrag von Hans-Martin »

Markush hat geschrieben: 12.11.2021, 20:09zu dieser Thematik Jitter und Einfluss / Störungen der digitalen Übertragung denk ich auch sehr spannend sind die Ausführungen hier: https://audiophilestyle.com/forums/topi ... nt=1064795
Hallo Markus
spannend finde ich das nicht, vermutlich geht das manchem langjährigen Forenten ebenso. Der Erfahrungshorizont dieses Forums ist schon lange erheblich weiter, wie eine Forumssuche nach den entsprechenden Schlagworten aufzeigen wird.
Wer erst in diesem Jahr dieses Forum entdeckt hat, mag sich wundern, wo wir schon vor 10 Jahren standen.
Seit 30 Jahren gibt es Jitter-Killer, Testberichte über die verschiedenen Ansätze, und die Erkenntnis, dass Jitter vielschichtig ist, Kaskadieren unterschiedlicher Geräte Sinn machen kann, Gert hat ausführlich dargestellt, welche Rolle der Fangbereich einer PLL dabei spielt und wie man den automatisiert. Und es mag verblüffen, dass 2 von derselben Clock nacheinander getaktete Flipflops noch eine Steigerung bringen können. Und on-top Fujaks Reclocker-Erkenntnisse....
Grüße
Hans-Martin
Bild
beltane
Aktiver Hörer
Beiträge: 3164
Registriert: 14.11.2012, 09:58
Wohnort: Hannover und Göttingen

Beitrag von beltane »

Hallo zusammen,

wenn ich diese Seite richtig verstanden habe:

https://community.roonlabs.com/t/whats- ... a/57376/10

stellt RAAT dem DAC die Daten letztlich im asynchronen Modus zur Verfügung. Das ist bei jeder DAC Anbindung mittels USB so.

Und auch bei diesem Streaming über USB, das die Musikdaten dem DAC im asynchronen Modus übermittelt (also ähnlich RAAT), verbessert ein vorab per Masterclock und Reclocking optimiertes Signal den Klang. Auch das konnte bisher niemand erklären.

Damit will ich nur sagen: Wir verfügen anscheinend nicht immer über das Wissen, die Ursachen für klangliche Verbesserungen erklären zu können. Dies gilt aus meiner Sicht daher auch für RAAT.

Viele Grüße

Frank
Bild
chriss0212

Beitrag von chriss0212 »

Hallo Hans-Martin

Ohne das Gehörte von Fujak anzuzweifeln, gibt es auch zum Daisy Chain von MC3 einen Test:

https://goldensound.audio/2021/10/05/m ... surements/

Messtechnisch schneidet der Mutec gar nicht mal so gut ab… vielleicht reagiert er deswegen auch so positiv auch auf sehr preiswerte 10MHz clocks…

Grüße

Christian
Antworten