Dante vs AES67: Ein interoperables Audio-Netzwerk planen

Kurzantwort — Dante ist eine vollständige kommerzielle Audio-Netzwerkplattform; AES67 ist ein Interoperabilitätsstandard für kompatible Audio-over-IP-Streams. Unterstützte Dante-Geräte können AES67-RTP-Multicast-Audio mit nicht-Dante AES67-Endpunkten austauschen, aber das Aktivieren des Modus ist nur der Anfang. Die Endpunkte brauchen weiterhin kompatible Audioformate, Multicast-Adressierung, PTPv2-Clocking, Netzwerkrichtlinien und getestete Subscriptions. Verwenden Sie native Dante-Verbindungen weiter für Dante-zu-Dante-Routen, außer das Design erfordert ausdrücklich eine AES67-Grenze.

Dante und AES67 lösen unterschiedlich große Aufgaben

Dante und AES67 werden oft so verglichen, als wären sie zwei austauschbare Produkte. Das sind sie nicht.

Dante bietet Geräteerkennung, Routing, Clocking, Monitoring, Konfiguration und Medientransport über ein unterstütztes Ökosystem. AES67 definiert eine gemeinsame Methode, mit der professionelle Audio-over-IP-Systeme unkomprimierte Audio-Streams austauschen können. Es standardisiert jedoch nicht alle Steuerungs-, Discovery-, Sicherheits- oder Management-Funktionen rund um diese Streams.

Die praktische Frage lautet daher nicht: „Was setzt sich durch?“ Sondern: „Wo braucht das System eine standardbasierte Audio-Grenze, und wer verantwortet jede Einstellung an dieser Grenze?“

Verwenden Sie innerhalb eines Dante-Systems natives Dante

Wenn beide Endpunkte Dante-Geräte sind, kommunizieren sie normalerweise über natives Dante-Transportprotokoll, auch wenn der AES67-Modus aktiviert ist. Das Aktivieren von AES67 wandelt nicht jede Route in AES67 um und verbessert keine gewöhnliche Dante-zu-Dante-Subscription.

Nutzen Sie den nativen Pfad, wenn er die Produktionsanforderung bereits erfüllt. Er erhält das erwartete Dante-Naming, Routing, Monitoring und den Recovery-Workflow. Ergänzen Sie AES67 nur dann, wenn ein kompatibler nicht-Dante-Endpunkt Audio über eine bewusst gestaltete Schnittstelle senden oder empfangen muss, etwa an einer Broadcast-, Installations-, Console-, DSP- oder Recording-Grenze.

Diese Unterscheidung verhindert einen häufigen Fehler: ein stabiles natives Netzwerk zu verändern, nur weil jedes Gerät eine Interoperabilitätsoption anbietet.

Bestätigen Sie, dass jeder Endpunkt den benötigten Modus unterstützt

AES67-Support ist eine Gerätefunktion, keine Garantie, die automatisch an jedem Netzwerkport hängt. Bevor die Show weitergeht, inventarisieren Sie:

• exaktes Produkt und Interface;
• installierte Firmware- und Dante-Software-Version;
• unterstützter RTP- oder AES67-Modus;
• unterstützte Samplerates, Kanalanzahl und Paketformate;
• Einschränkungen bei Multicast-Adressen;
• PTPv2-Clock-Optionen und Domain-Verhalten;
• ob ein Moduswechsel einen Reboot erfordert;
• wie der nicht-Dante-Endpunkt den Stream ankündigt oder annimmt.

In aktuellen Dante-Controller-Versionen stellen kompatible Geräte RTP- oder AES67-Konfigurationssteuerungen bereit. Ältere Produkte können engere Grenzen bei Adresse, Flow oder Clocking haben. Verwenden Sie die Dokumentation für die eingesetzte Firmware, statt anzunehmen, dass ein erfolgreich getestetes Gerät für die gesamte Flotte gilt.

Behandeln Sie die AES67-Route als definierten Multicast-Flow

AES67-Interoperabilität verwendet RTP-Multicast-Flows. Ein Sender erstellt einen Stream mit Audioformat, Ziel-Multicast-Adresse, UDP-Port und Timing-Verhalten. Der Empfänger muss diese Werte unterstützen und denselben Stream beitreten.

Definieren Sie den Flow, bevor Sie Subscriptions anlegen:

Einige Dante-Implementierungen empfangen AES67-Flows nur innerhalb bestimmter Multicast-Bereiche. Eine Subscription kann auch scheinbar akzeptiert werden, obwohl kein Audio ankommt, wenn das konfigurierte RTP-Präfix des Empfängers nicht zum übertragenen Flow passt. Dokumentieren Sie die tatsächlich eingesetzten Anforderungen statt eines generischen Adressbeispiels.

Zur breiteren Entscheidung über Fanout siehe Dante Unicast versus Multicast.

Bauen Sie PTPv2-Clocking als eigenen Arbeitsschritt auf

AES67 hängt von PTPv2-Timing ab. Native Dante-Netzwerke haben ihr eigenes Clock-Election-Verhalten, daher muss ein interoperables Design ausdrücklich festlegen, wie die relevanten Geräte eine kompatible PTPv2-Referenz erreichen.

Prüfen Sie:

1. welches Gerät oder welche Clock berechtigt ist, die AES67-Timing-Domain anzuführen;
2. welche PTP-Version und Domain-Nummer jeder beteiligte Endpunkt verwendet;
3. ob die Dante-Geräte automatische oder manuelle AES67-Clock-Konfiguration nutzen;
4. ob irgendein Gerät das erforderliche Timing-Verhalten zwischen nativer und AES67-Seite überbrückt;
5. DSCP und Switch-Behandlung für PTP-Event- und General-Messages;
6. die Auswirkungen auf den Ausfall des Leaders, eines Uplinks oder eines Endpunkts.

Gehen Sie nicht davon aus, dass sichtbare Geräte eine nutzbare Clock gemeinsam haben. Discovery, Steuerung und Media-Timing sind getrennte Prüfungen. Der Dante-Clock-Leader-Guide erklärt die native Dante-Election; die AES67-Grenze braucht zusätzlich ihre eigene PTPv2-Verifikation.

Halten Sie Multicast innerhalb eines bewussten Netzwerkscopes

Ein AES67-Stream ist kein Grund, jeden Port zu fluten. Karten Sie den VLAN- und Switch-Pfad und konfigurieren Sie dann die Multicast-Kontrollen für dieses Design.

Ein verwaltetes Netzwerk kann IGMP-Snooping nutzen, damit der Stream nur an Ports mit interessierten Receivern gesendet wird, wobei ein korrekt platzierter Querier die Mitgliedschaft aufrechterhält. Die genaue Policy liegt beim Netzwerkeigentümer. Bestätigen Sie, dass PTPv2, Discovery, wo erforderlich, und RTP-Multicast die vorgesehenen Endpunkte erreichen, ohne in andere Produktionsnetzwerke auszuweichen.

Prüfen Sie außerdem die Link-Kapazität in beide Richtungen. Multicast spart die Fanout-Last des Senders, aber jeder Flow verbraucht weiterhin Bandbreite auf jedem Link, der ihn transportiert. Der Dante-Leitfaden zu Netzwerkswitch-Anforderungen behandelt Link-Speed, QoS, EEE, Zähler und Abnahmetests.

Testen Sie die Interoperabilität von der Stille bis zur Wiederherstellung

1. Sichern Sie die bekannte native Basislinie

Exportieren Sie die aktuelle Dante-Konfiguration und protokollieren Sie Clock, Routen, Samplerates, Namen, Adressen und den Switch-Status. Schützen Sie funktionierende Outputs, bevor Sie einen neuen RTP-Modus aktivieren.

2. Konfigurieren Sie jeweils nur eine Grenze

Aktivieren Sie den benötigten Modus nur auf unterstützten Endpunkten. Wenden Sie das vereinbarte Format, das Multicast-Präfix, die Latenz und die PTPv2-Einstellungen an. Lassen Sie einen eventuell erforderlichen Reboot vollständig abschließen, bevor Sie das Ergebnis beurteilen.

3. Erstellen Sie einen eindeutig identifizierbaren Test-Flow

Beginnen Sie mit einem kleinen Kanalset und einer unmissverständlichen Testquelle. Protokollieren Sie Kanalreihenfolge, Multicast-Adresse, Port und Sender. Vermeiden Sie es, mehrere anonyme Flows gleichzeitig zu erzeugen.

4. Subscriben Sie und prüfen Sie jede Ebene

Bestätigen Sie, dass der Receiver dem vorgesehenen Flow beitritt, auf die korrekte Clock lockt, keine Fehler meldet und das richtige Audio am erwarteten Ausgang liefert. Eine Routing-Anzeige allein ist kein Beweis für hörbares, korrekt identifiziertes Medium.

5. Lastbedingungen realistisch abbilden

Fahren Sie die geplanten nativen Dante-Routen, AES67-Streams und repräsentativen Shared Traffic gemeinsam. Beobachten Sie Clock-Status, Latenz, Paketfehler, Link-Auslastung, Queues und tatsächliche Ziele.

6. Ausfall und Rollback testen

Entfernen und stellen Sie Quelle, Receiver, Clock-Leader und den relevanten Netzwerk-Link jeweils einzeln wieder her. Messen Sie Stummschaltung und Recovery-Verhalten. Beweisen Sie am Ende, dass die dokumentierte Basislinie ohne neue Annahmen wiederhergestellt werden kann.

Dokumentieren Sie die Interoperabilitätsgrenze

Der Rider sollte enthalten:

• den betrieblichen Grund für den Einsatz von AES67;
• native Dante- und AES67-Endpunkte nach Gerät, Port und Kanal;
• Firmware und Verantwortlichen für die Kompatibilität;
• Audioformat und Kanalreihenfolge;
• RTP-Multicast-Adresse, Port und zulässigen Bereich;
• PTPv2-Leader, Domain, Prioritäten und Fallback;
• VLAN, Switches, IGMP-Verantwortlichen, QoS und Link-Kapazität;
• Receiver-Latenz und Nachweis der Abnahme;
• Reboot-, Fehler-, Ersatz- und Rollback-Verfahren;
• die Technikerin oder den Techniker, der jede Seite ändern darf.

Platzieren Sie keine Passwörter oder sensiblen Netzwerkanmeldedaten in einem öffentlichen Rider. Teilen Sie diese über den vom Venue genehmigten sicheren Kanal.

Der Leitfaden zum Tech Rider für digitale Audionetze zeigt, wie Sie diese Grenze neben der restlichen Show-Übergabe platzieren.

Dante-und-AES67-Checkliste

• AES67 ist für eine benannte nicht-Dante-Interoperabilitätsgrenze erforderlich.
• Jedes Endgerät und jede Firmware-Version unterstützt den gewählten Modus.
• Samplerate, Kodierung, Kanalreihenfolge, Multicast-Adresse und Port passen zusammen.
• Die PTPv2-Quelle, Domain, Priorität und der Fallback sind verifiziert.
• Multicast-Scope, Querier, QoS, EEE und Link-Kapazität sind freigegeben.
• Die Route besteht korrekte-Audio-, Voll-Last-, Fehler- und Recovery-Tests.
• Native Dante-Routen bleiben dokumentiert und wiederherstellbar.
• Der Owner und das Rollback-Verfahren stehen im Rider.

Häufige Fehler

AES67 als vollständiges Steuerungssystem behandeln. Es standardisiert einen interoperablen Media-Pfad, aber nicht jedes Discovery-, Routing-, Sicherheits- oder Monitoring-Verhalten.

AES67 auf jedem Dante-Gerät aktivieren. Aktivieren und konfigurieren Sie es nur dort, wo eine freigegebene nicht-Dante-Grenze es erfordert.

Die Route prüfen, aber nicht die Clock. Ein Receiver kann einen Stream entdecken, aber ohne kompatibles PTPv2-Timing kein stabiles Audio ausgeben.

Multicast-Werte blind kopieren. Adressbereiche, Präfixe, Ports und Geräteunterstützung müssen zum tatsächlichen Endpunkt und Netzplan passen.

Einen Stream auf einem ungenutzten Switch testen. Die Abnahme muss native Routen, die geplante AES67-Last, Shared Traffic, Ausfälle und Recovery einschließen.

FAQ

Was ist der Unterschied zwischen Dante und AES67?

Dante ist eine vollständige vernetzte Medienplattform mit Routing, Discovery, Clocking, Monitoring und Gerätekonfiguration. AES67 ist ein Standard, der kompatiblen Audio-over-IP-Systemen den Austausch von RTP-Audio-Streams ermöglicht.

Ist Dante mit AES67 kompatibel?

Unterstützte Dante-Geräte können AES67-Audio zu und von kompatiblen nicht-Dante AES67-Geräten senden und empfangen. Die Kompatibilität hängt vom Gerät, der Firmware, dem Audioformat, den Multicast-Einstellungen und der PTPv2-Konfiguration ab.

Verwendet AES67 Multicast?

AES67-Interoperabilität nutzt üblicherweise RTP-Multicast-Streams. Sender, Receiver, Switches, VLAN, Multicast-Adresse, Port und IGMP-Policy müssen alle zum selben Plan passen.

Benötigt AES67 PTPv2?

Ja. AES67 nutzt PTPv2 zur Synchronisation der Medien-Clock. Die teilnehmenden Endpunkte müssen eine kompatible PTPv2-Konfiguration und einen passenden Timing-Pfad teilen.

Wie testet man die Interoperabilität von Dante und AES67?

Prüfen Sie die Fähigkeiten und Formate, konfigurieren Sie PTPv2, erstellen Sie einen bekannten RTP-Multicast-Flow, bestätigen Sie korrektes Audio am Ziel und testen Sie anschließend Voll-Last, Ausfall von Clock und Links, Rückkehr von Endpunkten und Rollback.

Halten Sie die Standards-Grenze rückbaubar

Speichern Sie die freigegebene Endpunktzuordnung, den RTP-Flow, den Clock-Plan, den Netzwerkscope, die Testnachweise und das Rollback zusammen mit der restlichen Show-Dokumentation. In Techrider.live bewahren Sie es im selben Rider wie den Bühnenplan und die Kanalliste auf, laden Sie die verantwortliche Ingenieurin oder den verantwortlichen Ingenieur zum Bearbeiten ein und speichern sowie prüfen Sie die Historie, bevor Sie die aktuelle Version teilen.