AVB Academy - Milan/AVB knowledge base

    Zitat von Christian Hofmann

    Gibt es denn schon nutzbare Lösungen, um z. B. AVB und layer3 Protokolle wie Dante oder controlling von Geräten über EIN bestehendes Netzwerk zu schicken, z. B. Über einen Glasfaser Strang mit z. B. Netgear AV oder luminex switchen? Auch redundant (im Falle von Dante oder AVB)?

    Also ich bin mir nicht 100% sicher ob ich die Frage richtig verstehe. Es sei mir also verziehen wenn die Antwort nicht passt ;)

    Ich nutze gelegentlich luminex-switche über die ich Avb, Dante, artnet und vielleicht noch Internet schicke. Alles hat natürlich sein eigenes VLan und geht über einen gemeinsamen Glasfasertrunk auf die andere Seite. Das funktioniert auf jeden Fall völlig problemlos.

    Zitat von felixgrampp

    Also ich bin mir nicht 100% sicher ob ich die Frage richtig verstehe. Es sei mir also verziehen wenn die Antwort nicht passt ;)

    Ich nutze gelegentlich luminex-switche über die ich Avb, Dante, artnet und vielleicht noch Internet schicke. Alles hat natürlich sein eigenes VLan und geht über einen gemeinsamen Glasfasertrunk auf die andere Seite. Das funktioniert auf jeden Fall völlig problemlos.

    Ja, das meinte ich. Danke

    Hallo zusammen,

    hier entstehen gerade eine paar ziemlich interessante Diskussionen, denen ich nicht viel hinzuzufügen habe. Freut mich auf jedenfall!

    Zwei Kommentare habe ich aber noch. Ich fange mal an:

    Zitat von gemini

    Christian: Sowohl Dante wie auch AVB benutzen PTP, timing ist also auch das gleiche.

    Die Antwort wird ein bisschen technisch, aber ich versuche mich so kurz wie möglich zu halten.

    Dante verwendet in der Regel PTPv1, das 2002 standardisiert wurde. Die Betonung liegt auf „in der Regel“, denn es gibt inzwischen auch PTPv2-Support. Genauere Details dazu habe ich gerade nicht zur Hand – vielleicht kann hier jemand mit Dante-Zertifizierung weiterhelfen?

    Dante synchronisiert End-to-End. Das bedeutet, dass der Clock Master seine Nachrichten durch das gesamte Netzwerk sendet. Das gesamte Netzwerk besteht aus mehreren Switches, die die Clock Nachrichten weiterleiten. Dadurch hat die Netzwerklatenz einen großen Einfluss auf die Präzision.

    Milan nutzt das generalized Precision Time Protocol (gPTP), das 2011 standardisiert wurde. Es basiert auf einem Profil von PTPv2.

    Milan verwendet eine Port-to-Port-Synchronisation. Hier sendet der Clock Master seine Zeitinformationen nur zum nächsten Netzwerkport (also der nächste Switch), wo diese Information dann verarbeitet wird. Anschliessend wird dann in gleicher Manier die latenzkompensierte Zeitinformation an den nächsten Port (aka nächster Switch) weitergeleitet. Dadurch wirkt sich die Netzwerklatenz weniger stark auf die Präzision aus.

    Ich habe das Thema in der AVB Academy beschrieben, aber ein bildlicher Vergleich zwischen den beiden PTP-Versionen wäre wahrscheinlich noch anschaulicher (Ich setze das mal auf die ToDo Liste):

    Network Timing :: AVB Academy
    Info A Milan network has one clock leader. The BTCA is executed automatically each time a change in the network occurs to elect a GrandMaster (GM). The GM is…
    avb-academy.com

    ---

    Zitat von karel noon

    Wir müssen immer noch ein wenig das Henne - Ei Problem lösen, Eier wurden genug gelegt, also Lautsprecher ( alleine ca. 15.000 Milan fähige nur von HK, bereits am Markt beim Kunden).

    Was fehlt ist die Henne, also passende Karten für Pulte, oder praktische Konverter.

    Hier kann ich nur zustimmen. Aber wenn jetzt jeder hier im Forum bei seinem Lieblings-Pulthersteller mal anfragt wann Milan endlich kommt, wird die Lösung für dieses Problem massiv beschleunigt ;)

    ---

    Liebe Grüße

    Simon

    Zitat von gäbsn

    Dante synchronisiert End-to-End. Das bedeutet, dass der Clock Master seine Nachrichten durch das gesamte Netzwerk sendet. Das gesamte Netzwerk besteht aus mehreren Switches, die die Clock Nachrichten weiterleiten. Dadurch hat die Netzwerklatenz einen großen Einfluss auf die Präzision.

    Das mit dem Einfluss verstehe ich gerade nicht:

    Solange die Netzwerklatenz unterhalb der eingestellten Dante-Latenz bleibt (was man im Dante Controller überwachen kann) fällt doch das Signal am Empfänger hinter dem Buffer zum richtigen Zeitpunkt raus. Die einzige potenzielle Klangveränderung kommt dann durch die Wandler und möglichen Samplingjitter der internen Wordclock.

    Mag sein, dass sich im Grenzbereich dann Vorteile ergeben, aber hat hier AVB/Milan nicht eh schon die Nase vorn, weil es (3/4?) Bandbreite einfach mal für die entsprechenden Daten reserviert.

    Der Netzwerkjitter wird auch ganz gern von den „Hifi HighEndern“ angeführt - aber der hat ja nichts mit dem Samplingjitter zu tun. (Sonst würde das ganze Streamingding überhaupt nicht funktionieren.)

    Zitat von audiobo

    Das mit dem Einfluss verstehe ich gerade nicht:

    Solange die Netzwerklatenz unterhalb der eingestellten Dante-Latenz bleibt (was man im Dante Controller überwachen kann) fällt doch das Signal am Empfänger hinter dem Buffer zum richtigen Zeitpunkt raus. Die einzige potenzielle Klangveränderung kommt dann durch die Wandler und möglichen Samplingjitter der internen Wordclock.

    Hi,

    Guter Punkt! Hier gibt es eine begriffliche Überschneidung:

    • Dante-Latenz (wie sie im Dante Controller eingestellt und überwacht wird) bezieht sich auf die Pufferung beim Empfänger – also darauf, dass das Audio-Signal trotz Jitter oder Verzögerungen im Netzwerk zuverlässig zum richtigen Zeitpunkt ausgegeben wird.
    • Netzwerklatenz in meinem Kontext meint die Verarbeitungsverzögerung der Pakete in den Switches. Diese wirkt sich auf die Präzision der Clock-Synchronisation aus.

    Dante arbeitet End-to-End: Der Clock Master sendet seine Zeitstempel durch das gesamte Netzwerk, und die Verzögerungen durch Switches müssen dabei berücksichtigt werden. Je nach Netzwerklast kann das zu Ungenauigkeiten führen, besonders wenn die Netzwerklast variiert.

    Milan arbeitet mit einer Port-to-Port-Synchronisation, bei der jeder Switch die Zeitinformation verarbeitet und korrigiert (Latenzkompensation), bevor sie weitergegeben wird. Dadurch bleibt die Clock-Synchronisation genauer, unabhängig von variierenden Netzwerklasten.

    Kurz gesagt: Die Audio-Latenz bleibt bei Dante durch den Puffer stabil, aber die Netzwerklatenz beeinflusst die Präzision der Clock-Synchronisation. Ich hoffe, das macht das ganze etwas klarer.

    Zitat von audiobo

    [...] aber hat hier AVB/Milan nicht eh schon die Nase vorn, weil es (3/4?) Bandbreite einfach mal für die entsprechenden Daten reserviert.

    Das ist ein häufiges Missverständnis. Milan reserviert nicht pauschal 75 % der Bandbreite für AVB-Traffic. Vielmehr können bis zu 75 % der verfügbaren Bandbreite für Milan-Streams genutzt werden – falls erforderlich.

    Das bedeutet: Wenn du nur einen einzelnen Stream mit z.B. 8 Audiokanälen von einem Talker zu einem Listener sendest, dann wird auch nur die tatsächlich benötigte Bandbreite reserviert. Der Rest steht für jeglichen anderen Traffic zur Verfügung.

    Eine detaillierte Erklärung dazu findest du in der AVB Academy, inklusive eines Cheatsheets zur benötigten Bandbreite je nach Streamkonfiguration:

    Stream Reservation Protocol (SRP) :: AVB Academy
    When a Listener is configured to listen to a specific Talker stream, the SRP protocol ensures that the required bandwidth is available on the entire path from…
    avb-academy.com

    Liebe Grüße

    Simon

    Zitat von gäbsn

    die Netzwerklatenz beeinflusst die Präzision der Clock-Synchronisation. Ich hoffe, das macht das ganze etwas klarer.

    Über wie viel Ungenauigkeit reden wir denn da? Und wie äussert sich das? In Samplingjitter, Sprüngen oder eher wie eine Gleichlaufschwankung? Bzw. kann das schon bei einer einzelnen Senke komisch werden oder ist das erst relevant wenn viele Senken absolut synchron sein müssen? (Array)

    Zum Thema Clock bei Dante:

    Grundsätzlich hat ja jedes Dante Gerät im Netzwerk seine eigene Clock (ausgenommen die Virtual Soundcard). Diese Uhren laufen quasi immer. Der Clock master (preferred oder automaitsch selbst gesetzt) sendet nun seine "Master" Zeit durchs Netzwerk, mit Hilfe derer die Clocks der einzelnen Geräte synchronisiert werden. Audinate garantiert eine Genauigkeit von 1-2 microsekunden (Laut den Unterlagen vom Level 3). Ein Sample bei 48kHz sind ca. 20mikroskunden

    Somit ist es fast ausgeschlossen, dass die Clocks sehr weit auseinander divergieren. Fällt die Master Clock aus, wird somit im Netzwerk sofort ein beliebiges Gerät zur Master Clock "ernannt" und übernimmt.

    Zitat von steffen r

    Ich weiß, passt nicht ganz genau hier her, aber kann das mal jemand für Ravenna erklären?
    Also was da der Unterschied zu Dante und Milan ist?

    Das Streamformat und wie der Stream aufgebaut wird, zudem ist sehr viel öffentlich bekannt. Ravenna und Dante unterstützen AES67, das ist der kleinste gemeinsame Nenner. Womit es möglich ist Streams zu migrieren.

    AVB unterstützt vom Protokoll auch IP basierte Streamformate ist also Technisch in der Lage AES67 Streams umzugehen.

    Ravenna,Dante IP basierende Techniken, AVB,Milan Layer2.

    Ravenna,Dante funktioniert mit Standard Switches, AVB, Milan benötigen spezielle Switches dafür müssen diese nicht vom Anwender konfiguriert werden. Auf Protokollebene wird alles erledigt das ein Stream sicher aufgebaut wird.

    Zitat von Christian Hofmann

    Level 3). Ein Sample bei 48kHz sind ca. 20mikroskunden

    Somit ist es fast ausgeschlossen, dass die Clocks sehr weit auseinander divergieren.

    TSN -> AVB 10ns !!!! -> boundary clock

    Nun es kommt auch auf die Hardware an, zunächst läuft der Takt ja frei weiter bis dieser wieder korrigiert wird. Läuft dieser zu weit weg kann man in der Hardware nicht einfach so hart den Clock verdrehen. Die folge ist dann der DropOut. Man hat sich bei der Takterzeugung bei Dante Geräten besonders viel Mühe gegeben das diese wenig driften, jedenfalls so das sie ohne PLOP wieder eingefangen werden können.

    Hallo Zusammen.
    Ich möchte hier das Marketinggescherei von wegen "AVB ist genauer" richtig stellen.

    PTP verteilt eine Zeit im Netzwerk (also z.b. Beim nächsten Ton ist es Montag der 4. März 09:48 und 7 Sekunden und noch ein paar Nanosekunden).

    Davon muss jedes Endgerät den MediaClock ableiten, sprich bei 48kHz muss das Gerät jede Sekunde in 48'000 Stücken teilen. Weil im Netzwerk die Clock Pakete abundzu etwas früher und abundzu etwas später beim Gerät ankommen hat das Gerät einen PLL. Dieser mittelt den Clock über eine gewisse Zeitspanne. Gewisse Hersteller machen das besser, andere schlechter. (man Merke: Ein Gerät was länger hat zum locken, schwingt in der Regel auch länger gleich ;)) Es ist aber immer Sache des Endgeräts diesen MediaClock zu erstellen, sprich des Wandlers.

    Wenn die PTP Zeit natürlich genauer ist und weniger Jittert (schwankt), das macht es wenn im Netzwerk sonst noch sachen los sind, ist es für die Endgeräte einfacher, einen schönen MediaClock davon abzuleiten.

    Hier schreibt AVB vor, dass alle Switche in der Kette PTP in der Hardware unterstützen müssen und somit einen viel kleineren PTP Jitter generieren als z.B ein Cisco SG300.

    Dante schreibt das nicht vor, trotzdem kann man die genau gleichen Switche mit der gleichen Hardware Unterstützung nutzen (z.B Luminex und Netgear mit Boundary Clock oder Transparent Clock).

    Man muss aber nicht und kann auch Switche in der Kette haben die diese Unterstützung nicht haben.

    Für Ravenna/AES67/SMPTE2110/IPMX gilt das gleiche wie für Dante.

    Dante nutzt von Haus aus PTPv1, kann aber auch PTPv2. Das sind IP basierte Protokolle.

    Da AVB nur mit MAC Adressen arbeitet nutzt AVB gPTP.

    Liebe Grüsse

    Hallo in die Runde,

    bitte erlaubt mir eine Nachfrage: ich vermisse nach wie vor Milan Sender oder Milan Break-In Tools, damit die täglich wachsende Liste der Milan Empfänger auch etwas zu empfangen haben. Hat jemand von euch vielleicht interessante Informationen oder Produktempfehlungen? Danke schon mal im Voraus!

    Grüße,

    Jürgen

    Zitat von gemini

    Wenn die PTP Zeit natürlich genauer ist und weniger Jittert (schwankt), das macht es wenn im Netzwerk sonst noch sachen los sind, ist es für die Endgeräte einfacher, einen schönen MediaClock davon abzuleiten.


    Einige Konzepte erzeugen aus dem PTP Clock den CPU,PHY Clock. Ein Wackeln der PTP hat dann auch Auswirkungen auf die Echtzeitfähigkeiten der CPU. Bei einer CPU kann man den Clock nicht beliebig verstellen, das kann nur minimal erfolgen. Das hat damit zu tun das z.Bsp zugriffe auf Speicher ein korrektes Timing nötig ist. Ein plötzliches nachziehen des Taktes kann zu Fehlern in der Verarbeitung führen.

    Darin ist er der Grund weshalb das synchronisieren etwas lange dauern kann, bis der Clock Phasengenau synchronisiert wurde. Oder auch gar nicht, kommt auch schon mal vor wenn wie beim Raspberry CM4 die Takterzeugung Käse ist.

    Bei AVB hat die Industrie sehr viel beeinflusst, 10nS braucht man in der AV Industrie nicht.