AVB Academy - Milan/AVB knowledge base

    Zitat von gemini

    Wie gesagt ich bin wirklich kein verfechter von Audinate, ich bin auch für offene Technologien, aber trotzdem muss man korrekt bleiben.

    Keysight ist nicht bekannt dafür, inkorrekte Messungen vorzunehmen. Im Gegenteil, die sind führend im Bereich Messtechnik für Netzwerke. Ich wüsste nicht, was hier 'inkorrekt' ist. Es scheint eine Frage der Interpretation zu sein.

    Die Fragestellung war, ob das AVB gPTP wirklich besser ist (stabiler, genauer, zuverlässiger) als PTP V1 oder PTP V2. Wie die Ergebnisse zeigen, lässt sich gPTP auch durch massiven anderen Traffic (95% Auslastung der Bandbreiten in diesem Experiment) nicht irritieren und bleibt unter 100ns PTP Jitter.


    Wie gesagt, in der Praxis wird man solche Auslastungen nicht konstant haben - das wäre sehr schlechtes Netzwerkdesign - aber als Spitzenbelastung ist das statistisch natürlich möglich und kann PTP V1 ordentlich aus dem Takt bringen. Ob das relevant ist kann man wohl nur im Einzelfall bewerten, aber es führt ja zu der best-practice Empfehlung, Dante und Best-Effort-Traffic in relevantem Ausmaß möglichst getrennt zu halten.

    Eine Frage an Gemini: Inwiefern unterstützt Dante PTP V2? Dante selbst läuft meines Wissens nur auf PTP V1 aber diverse Dante Hardware unterstützt AES67 und das basiert natürlich auf PTP V2.

    HeK


    Dass PTPv2 nach 6 Hops 4500ns jittert ist definitiv nicht korrekt. Ich baue PTP fähige Netzwerk und habe schon einige gemessen, wenn wir da 4500ns Jitter hätten, dann ist da was kaput ;)

    gPTP und PTPv2 nutzen die gleichen Mechanismen, bei einem steht ne Mac Adresse auf dem Paket, beim anderen ne IP und ne Mac Adresse, der Jitter wird darum nicht schlechter.


    Wenn du die Dante Module in den AES67 Modus setzt, wird PTPv2 aktiviert. Defakto können alle Dante Module PTPv2, ausser die Virtual Soundcard (und da gibts nen Hack, dass die das auch kann).

    Dante Devices PTP Clocking Support | Dante
    The following table is a generic guide aiming to summarise the PTP capabilities of Audinate’s End User and OEM products. Support for features like AES67 or…
    www.getdante.com

    PTPv2 soll auch standard werden bei Dante

    Es kann ;)

    Im Endgerät ist ein PLL. Dieser regelt Unregelmässigkeiten raus und macht eine Mittelung.

    Phasenregelschleife – Wikipedia

    Dies ist Hersteller abhängig wie gut dieser ist.

    Ich muss dafür bei Gelegenheit mal ein paar Messungen machen.


    Wenn der PTP natürlich stark jittert, ist es für den PLL schwieriger eine schöne Mittelung zu machen. Ein besserer machts besser, ein schlechterer schlechter.


    (Aka wenn jemand undeutlich englisch spricht versteh ichs unter umständen immer noch, je besser ich selber English verstehen kann. Wenn ich nicht so gut Englisch kann, werd ich eher mal ein Wort nicht verstehen und der ganze Satz wird ungenau ;) Desto genauer der Partner spricht, desto einfacher ist es für mich den ganzen Satz korrekt zu verstehen)

    Dieser wird in seine Phase und Frequenz synchronisiert. Wie stabil jener dann ist hängt weitestgehend von der Hardware ab. Wie schon erwähnt kann man den Clock nicht zu stark verschieben, es wird in kleinen Schritten korrigiert. RME hat schon recht früh viel Energie hinein gesteckt als einen schlechten Clock einen stabilen zu bekommen.


    Schlechte Taktgeber gab es auch schon vorher und die Probleme damit

    auch.

    Zitat von gemini

    Dass PTPv2 nach 6 Hops 4500ns jittert ist definitiv nicht korrekt.

    Diese Aussage hat in dieser Allgemeinheit niemand getroffen. Das Doc von Keysight berichtet von einem sorgfältig durchgeführten Experiment, welches zeigt, dass eine solcher PTP Jitter unter bestimmten Umständen auftreten KANN, was nicht besagt, dass er es unter allen Umständen tut.

    Ganz im Sinne der Korrektheit. (!)

    Zitat von audiobo

    Führt PTP-Jitter zu Samplingjitter, ja oder nein?

    Das hängt vom Spectrum des Jitters ab. Wenn der Jitter eher hochfrequent ist (schmale Spikes) dann wird die Trägheit der Empfänger PLL das in aller Regel gut genug ausregeln können.
    Wenn die Abweichungen sehr langsam ODER wenn sie asymmetrisch sind wird es eher problematisch.

    Bei PTPV1, was ja die Zeit der Übertragung durch alle Switch Hops hindurch zwischen den Endpoints misst, tritt dann leicht sogenannter 'Wander' auf (Ein 'Wegwandern' der Clock), wenn sonstiger Traffic durch die Switche asymmetrisch ist. Also wenn sehr viel Traffic in eine Richtung verläuft, so dass der Hinweg für die PTP Packete andere Latenzen aufweist als der Rückweg.

    Solche eher langsamen asymmetrischen Clock Ungenauigkeiten können zum Wegdriften einer PLL führen. Genaus das wurde in dem Experiment bei IXIA demonstriert, indem man Video Traffic unidirektional durch 6 Hops geleitet hat mit 95% Auslastung der Bandbreiten. Das ist gerade bei Video ja keine Seltenheit, das ein Netz in eine Richtung wesentlich mehr Traffic hat als in eine andere.

    Zitat von audiobo

    Eine Frage die für mich irgendwie immer noch nicht richtig beantwortet ist:


    Führt PTP-Jitter zu Samplingjitter, ja oder nein? M.M.n. sollte die Wordclock im Empfänger eine gewisse „Trägheit“ bei der Anpassung aufweisen damit das nicht passiert.

    Ja - da ist normalerweise eine gewisse "Trägheit"...
    Jitter in der PTP Synchronisation wird da durch einen Tiefpass geglättet.

    Auch die PLL's haben entsprechend noch einen Tiefpass falls die Zeit-Referenz jittert (kannst ja mal das Datenblatt von so einer CS2100 PLL dir durchlesen; Kapitel 5.2.2 - diese PLL ist quasi omnipräsent im Audio-Bereich bei so ziemlich allem, wo Audio-Clocks zurückgebildet werden müssen).

    Meiner Erfahrung nach ist eher das Risiko, falls die PTP-Pakete durch mehrere Hops ohne Boundary-Clock durchmüssen, ein gewisser "Offset" in der Zeitreferenz entsteht und die Samples nicht mehr sauber alligned sind.
    Als Veranstaltungstechniker kann man das kaum sinnvoll erfassen mithilfe der Tools, weil die Tools nur die zeitlichen Offsets anzeigen, die sie selber (potentiell auch leicht fehlerhaft) errechnet haben.
    Da muss man schon direkt an die Elektronik mit einem Oszilloskop dran und die Word-Clock Signale zwischen Prozessor/DSP und ADCs/DACs vergleichen über mehrere Knoten hinweg.

    Das kann dann durchaus auch mal deutlich größer werden als die 1µs die Dante in seinen Slides beteuert.

    Für die meisten Anwendungen sind paar Microsekunden offset egal. In Arrays kann ´man im Hochton da schon bisschen Phasenprobleme im HF bekommen.

    Ja, gut... wenn du als maximal zulässige Abweichung 1/4 Periodendauer bei 20kHz definierst, darfst du immerhin einen Offset bis 12.5µs haben. Das entspricht einem Wegunterschied von 4.5mm.

    Ich bezweifle, dass das bei einer realen Beschallung mit verschiedenen Temperaturzonen, Luftbewegung, unperfektem Abstrahlverhalten usw. auffallen würde.


    Schnell modulierend wäre es halt schon eher auffällig.


    Wenn wir jetzt noch von der Arraysituation ausgehen, dann wird bei einem halbwegs sinnvollen Setup vermutlich nur durch die Auslastung des letzten Switches die Differenz im PTP bei den Empfängern bestimmt, oder sehe ich das falsch?

    Zitat von audiobo

    Wenn wir jetzt noch von der Arraysituation ausgehen, dann wird bei einem halbwegs sinnvollen Setup vermutlich nur durch die Auslastung des letzten Switches die Differenz im PTP bei den Empfängern bestimmt, oder sehe ich das falsch?

    Nein es ist die gesamte Kette zwischen PTP Grandmaster-Clock und den Endknoten.
    Wenn z.B. in einem Dante-Netzwerk die Zeitreferenz z.B. das FOH Pult ist und dazwischen z.B. 4 Switche sind (selbst wenn das Array in sich selbst über einen letzten Endswitch geht), so laufen alle PTP Pakete im Ping-Pong immer zu/von der FOH Konsole.

    Außer eben wie bei AVB wenn jeder Switch eine Boundary-Clock macht.

    Als Anwender mit Musik drauf bekommt man das wackeln des Mediaclocks nicht mit. Selbst wenn man einen Ton mit 1khz abspielt müsst der Clock schon sehr stark abweichen bevor irgend was jault.


    Auch wenn man sagen wir eine Aktive PA hätte wo Digital Hi und Lo als getrennter Stream vorhanden ist wäre dies nur in der extreme vielleicht zu hören. Geht man von der üblichen Trennfrequenz von 80 - 100HZ aus spielt das kaum noch eine Rolle.

    Zitat von wora

    bei mir ist die masterclock immer das Dante netzwerk, alle angeschlossenen geräte sind slaves.

    Ich glaube du hast durch die Clock Source Einstellungen im Pult einen Denkfehler. Dante braucht immer einen Clock-Master, dem der Rest des Netzes hinterherläuft. Das ist in der Regel das Gerät mit der "besten" Clock (das Mischsystem) oder das Gerät, das als Preferred Master markiert ist.

    Wenn im Pult die Clock Source "Dante" ausgewählt ist, nimmt das Pult die Clock aus dem Netz. Die Clock im Netz kommt aber immer von einem der Geräte im Netz. Wenn also das Pult Clock Master ist, nutzt es seine eigene Clock - genau die, die auch im Netz verteilt wird. Grundsätzlich ist diese Einstellung die beste, weil damit bei einem Wechsel des Clock Masters alles weiterläuft.

    Für Spezialfälle (z. B. externe Clock) kann die Clock Source anders konfiguriert werden. Dann sollte man aber wissen, was man macht und etwas Hirnschmalz in die Sache stecken.

    Ähm... trennt doch mal "Wordclock" und "PTP"


    (Wordclock = Taktgeber "Metronom" für's Zusammenspiel im lokalen Umfeld,

    PTP = Absolutzeit "Kalender + Tageszeit" (oder für Trekkies auch "Sternzeit") für's synchronisierte Starten des Metronoms innerhalb unserer Milchstrasse)


    Zitat von HenrySalayne

    Wenn also das Pult Clock Master (PTP Master ?) ist, nutzt es seine eigene Clock - genau die, die auch im Netz verteilt wird.

    Das ist ist nämlich gerade höchst missverständlich - man sollte "Pult" und Dantechip als separate Einheiten ansehen, auch wenn sich der Dantechip im Controller als das Pult ausgibt:


    - Das Pult kann nur Wordclock - dem ist die Sternzeit egal

    - Das Netzwerk kann nur PTP - eine überall synchrone, zeitlineare Taktübertragung hätte gar keine Chance

    - Der Dantechip bildet die Brücke aus beidem. I.d.R. generiert dieser aus dem PTP eine Wordclock für das angeschlossene Gerät. Ausser wenn irgendwo "Sync to external" genutzt wird, dann geht das an der Stelle umgekehrt.


    btw. - ich finde diese Erklärung hier zum Thema PTP recht gelungen:

    PTP - Precision Time Protocol
    www.msxfaq.de

    Zitat von audiobo

    Das ist ist nämlich gerade höchst missverständlich - man sollte "Pult" und Dantechip als separate Einheiten ansehen, auch wenn sich der Dantechip im Controller als das Pult ausgibt:


    - Das Pult kann nur Wordclock - dem ist die Sternzeit egal

    - Das Netzwerk kann nur PTP - eine überall synchrone, zeitlineare Taktübertragung hätte gar keine Chance

    - Der Dantechip bildet die Brücke aus beidem. I.d.R. generiert dieser aus dem PTP eine Wordclock für das angeschlossene Gerät. Ausser wenn irgendwo "Sync to external" genutzt wird, dann geht das an der Stelle umgekehrt.

    Ja, da hast du recht.

    Hier ist es auch gut und kompakt zusammengefasst:

    Clock Synchronization

    Ich versuche es mal so zu erklären:

    - PTP in sich selber hat erstmal nichts mit dem Audio-Takt (also z.B. den 48/96 kHz) selber zu tun.

    PTP ist vergleichbar wie bei einem normalen Computer mit dem NTP Zeitdienst, der sicherstellt, dass alle Endknoten im Netzwerk die gleiche Zeit haben (nur eben mit einer Präzision, die in den Bereich von unter 10 Nanosekunden kommen kann). Die absolute Zeit (z.B. ob heute der 19. März 2024 um 8:55:23 + 39633µs + 177ns ist), ist erstmal egal.
    Oft läuft bei PTP die Zeit einfach nur bei 0 los, sobald irgendein Knoten erstmal autonom / unsynchronisiert startet.

    Zusätzlich (unabhängig von der PTP-Zeit) gibt es jetzt irgendeinen einen Taktgeber für den Audio-Takt (also z.B. unsere 48kHz) - dies kann wie z.B. bei Dante genannt ein externes Sync-Signal sein, oder kann im einfachsten Fall mithilfe eines Oszillators erzeugt werden (in der Praxis setzt man oft Oszillatoren ein, die dann aber eher zB 24.576 MHz haben und wird dann entsprechend runtergeteilt 24.576MHz / 512 -> 48k).

    Diese 48 kHz-Clock gibt dann z.B. den ganzen ADCs / DACs oder auch DSPs vor, wann jedes mal ein neues Sample zu verarbeiten ist (der ADC liefert dann genau in diesem Takt neue PCM-Werte, der DAC konsumiert genau mit diesem Takt PCM-Werte und generiert ein kontinuierliches analog-Signal).


    Die eigentliche Verknüpfung zwischen Audio-Takt und PTP-Zeit wird dann mithilfe von "Zeitstempel" gemacht - das funktioniert in etwa so:
    Bei AVB muss ein Gerät nominiert werden, welches "CRF (Clock Recovery Format) Talker ist".
    Dieser macht dann am Ende des Tages nichts anderes, als dass er sich im Abstand von X-Samples (bei AVB sind das glaube ich immer jedes 160. oder 320. Sample) sich die aktuelle PTP-Zeit notiert.

    Bei 48k hat man einen zeitlichen Sample-Abstand von ~20.833µs - bei einem Abstand von je 160 Samples würde der CRF-Master also eine Art kontinuierliche Liste erzeugen die etwa so aussieht:


    Sample X: PTP-Zeit: 19. März 2025 9:04:17 + 37ms 388µs 170ns

    Sample X+160: PTP-Zeit: 19. März 2025 9:04:17 + 40ms 721µs 503ns

    Sample X+320: PTP-Zeit: 19. März 2025 9:04:17 + 44ms 54µs 836ns
    Sample X+480: PTP-Zeit: 19. März 2025 9:04:17 + 47ms 388µs 170ns

    Jeder Knoten im Netzwerk, der jetzt die Audio-Clock "recovern" muss, macht das in etwa dann nach einem ähnlichen Prinzip.

    Der CRF-Master verteilt diese Referenz-Zeitstempel im Netzwerk und jeder Knoten macht für sich selber autonom nochmal ein zeitstempeln der eigenen Audio-Clock (also derjenigen die er "recovern" soll).
    Wenn ein Endknoten jetzt sieht, dass die Zeitstempel die lokal erzeugt werden z.B. immer 0.02% abweichen zu den "Referenz-Zeitstempeln" die vom CRF-Master kommen, dann muss der lokale Audio-Takt eben etwas schneller oder langsamer gemacht werden, sodass sich die Referenz-Zeitstempeln mit den lokalen "nachgemessenen" Zeitstempeln anfangen, übereinzustimmen.
    Sobald das einmal eingeregelt ist, bleibt das dann stabil.

    Die ganze Bedingung dass das funktioniert ist natürlich die Annahme, dass die PTP Zeit überall wirklich sauber synchronisiert werden muss. Nachdem man in der Praxis aber keine Möglichkeit hat, das wirklich nachzumessen, muss man sich eben darauf verlassen, dass die Netzwerk-Infrastruktur es hergibt, PTP sauber arbeiten zu lassen im Netzwerk.