Was ist AES67 – und warum ist es wichtig?

Audio-over-IP (AoIP) hat professionelle Audio-Workflows verändert, aber das Ökosystem war jahrelang fragmentiert. Jeder Hersteller – Dante, RAVENNA, Livewire, Q-LAN – verwendete proprietäre Protokolle, die nicht miteinander kommunizieren konnten. 2013 veröffentlichte die Audio Engineering Society AES67, einen offenen Interoperabilitätsstandard, der einen gemeinsamen Satz von Netzwerkprotokollen definiert, so dass Geräte verschiedener Anbieter hochwertiges Audio über Standard-IP-Netzwerke austauschen können. AES67 ersetzt diese proprietären Systeme nicht; es fungiert als "Brückenschicht", die es ihnen ermöglicht, zu koexistieren und zu interagieren, ohne dass jedes Gerät eine einzige geschlossene Plattform unterstützen muss.

AES67 wird heute in Broadcast-, Live-Sound-, Aufnahmestudios, Corporate AV und sogar in einigen installierten Soundanwendungen weit verbreitet eingesetzt. Es ist die Grundlage für andere AoIP-Standards wie SMPTE ST 2110-30 und trägt zum breiteren Vorstoß hin zur All-IP-Produktion bei. Das Verständnis der AES67-Architektur und -Protokolle ist nicht nur eine akademische Übung - es wirkt sich direkt auf Ihre Fähigkeit aus, ein modernes Audionetzwerk zu entwerfen, zu beheben und zu skalieren.

Kernkomponenten der AES67-Architektur

Ein AES67-Netzwerk basiert auf vier wesentlichen Säulen: Netzwerkinfrastruktur, Synchronisation, Medientransport und Discovery. Jede Komponente stützt sich auf etablierte Internet Engineering Task Force-Standards (IETF), die das System zuverlässig und herstellerunabhängig halten.

1. Netzinfrastruktur

AES67 läuft auf Standard-Ethernet, aber weil es isochrones Echtzeit-Audio transportiert, muss das Netzwerk bestimmte Mindestanforderungen erfüllen. IGMP-Schnüffel Multicast-Gruppen effizient zu verwalten, DiffServ QoS (Differentiated Services Code Point), um Audiopakete zu priorisieren, und VLAN-Abtrennung Um Steuerung und Medienverkehr zu trennen. Während 1 Gbps typisch ist, können große Sendeanlagen 10 Gbps oder höher verwenden. Jumbo-Frames (bis zu 9000 Bytes) sind optional, werden jedoch empfohlen, um den Paket-Overhead zu reduzieren.

Für einen zuverlässigen Betrieb sollten Netzwerkingenieure Strenge Prioritätswarteschlangen (in der Regel CoS 4 oder 5 für PTP, CoS 3 für Audio-RTP) und sorgen für eine Latenz-Weiterleitung. Switches sollten nicht mehr als einige Mikrosekunden Jitter einführen, da die PTP-Synchronisation von AES67 nur winzige Zeitabweichungen toleriert.

2. Synchronisation — Precision Time Protocol (PTP)

Alle AES67-Geräte müssen mit einer gemeinsamen Uhr synchronisiert werden. Die Standard-Mandate IEEE 1588-2008 Precision Time Protocol (oft als PTPv2 bezeichnet) verwenden die IEEE 1588-2008 Precision Time Protocol (oft als PTPv2). AES67-ProfilIm Gegensatz zu generischem PTP gibt das AES67-Profil eine Standard-Domänennummer an (Domäne 0) und verwendet zweistufiges Clock-Messaging mit Multicast. Die Grandmaster-Uhr ist normalerweise ein dedizierter PTP-Server, aber jedes Gerät im Netzwerk - ein Mikrofon, eine Mischkonsole oder eine Brücke - kann zum Grandmaster werden, wenn sie eine stabile Taktquelle hat.

Die Bester Master Clock Algorithmus (BMCA) In der Praxis sperren Rundfunkanstalten oft alle PTP-Domänen an eine GPS- oder GNSS-Referenz, wodurch eine Sub-Mikrosekunden-Synchronisierung über große Installationen hinweg erreicht wird. Ohne diese Präzision würden Audiopuffer versagen oder ausfallen.

3. Medientransport – Echtzeit-Transportprotokoll (RTP)

Audio-Samples werden in RTP-Pakete eingekapselt und über UDP übertragen. AES67 unterstützt übliche Abtastraten: 44,1, 48 und 96 kHz mit Bittiefen von 16 oder 24 Bit (und 32-Bit-Gleitkomma für den Intra-Studio-Einsatz). Kanäle pro Stream können zwischen 1 und 8 liegen (aber 4 ist typisch für die Interoperabilität mit anderen Standards wie SMPTE ST 2110-30).

RTP Payload Format ist L16 oder L24 AES67 erlaubt auch μ-law-Codierung für Kompatibilität mit älteren Telekommunikationssystemen, obwohl dies in professionellem Audio selten verwendet wird. Pakete werden als Multicast-UPD-Streams an eine Gruppenadresse gesendet; Empfänger abonnieren über IGMP. RTP-Kontrollprotokoll (RTCP) wird für Out-of-Band-Statistiken verwendet, aber nicht für die Taktwiederherstellung - die vollständig von PTP behandelt wird.

Die empfohlene Standardeinstellung beträgt 1 ms (mit einer zulässigen Ausgangsleistung von etwa 48 Samples pro Paket bei 48 kHz), einige Geräte unterstützen jedoch 0,125 ms für die Überwachung mit extrem niedriger Latenz und 4 ms für weniger kritische Verbindungen über überlastete Netzwerke.

4. Entdeckung und Registrierung

Geräte müssen wissen, welche Streams im Netzwerk verfügbar sind. AES67 hat sich ursprünglich auf die Session Announcement Protocol (SAP), die regelmäßig Stream-Beschreibungen (SDP-Format) an eine bekannte Multicast-Adresse (224.2.127.254) sendet. SAP ist einfach und leicht, kann aber in großen Netzwerken gesprächig sein.

Andere Discovery-Methoden existieren gleichzeitig mit AES67: RTSP (Real Time Streaming Protocol) kann für die Sitzungssteuerung verwendet werden, und neuere Erweiterungen wie mDNS/DNS-SD Der entscheidende Punkt ist, dass AES67 selbst kein Discovery-Protokoll definiert – es verlangt nur, dass Streams mit einer Session Description Protocol (SDP)-Datei beschrieben werden können. Es steht den Herstellern frei, jeden Discovery-Mechanismus zu implementieren, der SDP-Informationen übermittelt, solange ein Gerät eines Drittanbieters sie analysieren kann.

Schlüsselprotokolle im Detail

Während die vier Kernkomponenten die Architektur bilden, verdienen mehrere zugrunde liegende Protokolle einen genaueren Blick.

PTP (Precision Time Protocol) – Der Herzschlag

PTP tauscht zeitgestempelte Nachrichten zwischen dem Großmeister und allen Slave-Uhren aus. Das AES67-Profil arbeitet mit einer zweistufigen Operation: Der Großmeister sendet eine Sync-Nachricht, dann eine Follow Up-Nachricht, die die genaue Abfahrtszeit enthält. Slaves verwenden diese, um den Offset zu berechnen und ihre eigenen Uhren über einen Servoalgorithmus anzupassen.

Bei den meisten verwalteten Switches müssen PTP-Nachrichten die höchste Priorität erhalten und dürfen nicht durch Speicher- und Vorwärtsverarbeitung verzögert werden. Grenzuhren oder transparente Uhren (TC) auf Switches können Brückenverzögerungen kompensieren, aber in kleinen Netzwerken ist ein gewöhnlicher zweistufiger Ansatz ohne TC ausreichend. Der Standard verlangt, dass Endgeräte innerhalb von 2 Sekunden nach dem Start sperren und über ein 1-Sekunden-Intervall eine Drift unter 1 Mikrosekunde beibehalten - dicht, aber mit gutem Design erreichbar.

RTP (Real-Time Transport Protocol) – der Payload Carrier

RTP-Pakete tragen einen Header mit Sequenznummer, Zeitstempel und SSRC (Synchronisation Source Identifier). Das AES67-Profil gibt eine maximale Paketzeit von 4 ms an, wobei 1 ms bevorzugt wird. Da RTP über UDP läuft, findet keine erneute Übertragung statt; Paketverlust muss vorgelagert (z. B. über redundante Streams oder FEC, obwohl AES67 keine FEC beauftragt).

Häufige Fallstricke: Unpassende Paketzeiten zwischen Sender und Empfänger können zu Audioausfällen führen. Konfigurieren Sie beide Enden immer mit dem gleichen "ptime"-Parameter in der SDP-Datei. Überprüfen Sie auch, ob der Netzwerkpfad die RTP-Time-to-Live (TTL) nicht überschreitet. AES67 empfiehlt eine TTL von mindestens 10 für kleine Netzwerke.

SIP (Session Initiation Protocol) – ein hilfreiches Overlay

AES67 nennt SIP als eine mögliche Methode für Session Management und Stream Discovery, aber es ist selten der primäre Ansatz. In der Praxis verlassen sich die meisten AES67-Geräte auf SAP oder proprietäre Web-Schnittstellen. SIP ist häufiger in telekommunikationsorientierten AoIP wie VoIP oder SIP-basierte Sprechanlagen, die mit AES67-Bridges integriert sind.

Vorteile von AES67 in der realen Welt

Der Hauptvorteil ist Interoperabilität ohne Lock-in. Eine Sendeeinrichtung, die RAVENNA für Studio-zu-Sender-Verbindungen verwendet, kann Dante-ausgestattete Mikrofone akzeptieren; eine Live-Sound-Konsole kann einen Stream von einem Q-SYS-DSP abrufen. AES67 fungiert als universeller "Übersetzer", der in vielen Fällen die Notwendigkeit einer dedizierten Gateway-Hardware eliminiert.

Weitere Vorteile sind:

  • Skalierbarkeit: Da AES67 Standard-IP-Multicast verwendet, können Sie Hunderte von Streams hinzufügen, solange Ihre Switches die Anzahl und Bandbreite der Multicast-Gruppen verarbeiten können.
  • Kosteneffizienz: Keine proprietäre Netzwerkhardware erforderlich – hochwertige Off-the-Shelf-Switches funktionieren bei richtiger Konfiguration.
  • Zukunftssicher: Da SMPTE ST 2110 zur Norm im Broadcast wird, ist AES67 (das mit dem Audioteil von ST 2110-30 identisch ist) bereits vorhanden. Ein Studio, das heute ein AES67-Netzwerk aufbaut, kann später mit minimalen Änderungen auf den vollen ST 2110 Video-over-IP migrieren.
  • Zuverlässigkeit: PTP-basiertes Clocking beseitigt die Drift- und Jitter-Probleme, die ältere isochrone Netzwerke plagen. Die AES67-Toleranz für Paketverluste (bis zu 1% ohne kritisches Versagen in gut gepufferten Systemen) erhöht die Widerstandsfähigkeit.

Implementierungshandbuch - Aufbau Ihres ersten AES67-Netzwerks

Die Bereitstellung von AES67 erfordert mehr als nur das Einstecken von Geräten.

Schritt 1: Gerätekompatibilität überprüfen

Wenn Sie beispielsweise Dante und RAVENNA mischen, stellen Sie sicher, dass das Dante-Modul den optionalen AES67-Modus unterstützt (verfügbar bei vielen neueren Modellen). Einige ältere Geräte erfordern ein Firmware-Update.

Schritt 2: Entwerfen der Netzwerktopologie

Verwendung a Sterntopologie mit einem Kernschalter und einem Kantenschalter oder einem Rückenblatt für große Anlagen. IGMP-Schnüffel- und Querier-Schalter für jedes Audio übertragende VLAN aktivieren. Separate Steuerung und Audioverkehr: dedizierte VLANs für PTP und Stream-Multicast verringern das Risiko von Fehlkonfigurationen.

Statische IP-Adressen kritischen Geräten zuweisen (Großmeisteruhr, feste E/A-Einheiten). DHCP ist für Endpunkte akzeptabel, wenn der Mietvertrag lang ist, aber dynamische Adressen für PTP-Großmeister vermeiden.

Schritt 3: PTP konfigurieren

  • Bestimmen Sie einen primären Großmeister (z. B. einen GPS-gesperrten PTP-Server).
  • Stellen Sie sicher, dass alle Geräte das AES67-Profil verwenden (IEEE 1588-2008, 2-Schritt, Standarddomäne 0, Multicast).
  • Alle Schalter sind auf transparenten Taktmodus (falls unterstützt) oder Boundary-Clock-Modus zu stellen. Mindestens sollten sie keine PTP-Nachrichten filtern; stellen Sie sicher, dass PTP Ethernet Multicast erlaubt ist (MAC-Adresse 01-1B-19-00-00-00-00).
  • Monitor PTP-Offset auf jedem Gerät – es sollte < 1 μs sein. Wenn es 10 μs überschreitet, gibt es ein Netzwerk-Timing-Problem (Schaltverzögerung, CPU-Überlastung oder Jitter durch schlechte Verkabelung).

Schritt 4: Streams einrichten

Verwenden Sie die Web-Benutzeroberfläche oder Steuerungssoftware des Geräts, um einen Senderstrom zu erstellen. Erfassen Sie die SDP-Datei (oft als .sdp-Datei herunterladbar). Importieren Sie die SDP auf dem Empfänger oder verwenden Sie automatische Erkennung (SAP/mDNS). Überprüfen Sie, ob der Stream im Netzwerk erscheint: Sie können Wireshark mit dem Anzeigefilter verwenden, um Pakete zu sehen. Überprüfen Sie die SSRC - doppelte SSRCs zwischen Streams können Verwirrung bei Empfängern verursachen, die nicht mit der Anzeige umgehen.

Schritt 5: Testen und Validieren

  • Latenz zwischen Sender und Empfänger mit einem Ton und Oszilloskop oder einem RTP-Analysator-Tool messen. AES67s 1 ms Standard sollte über einen einfachen Schalter erreicht werden.
  • Testen Sie die Widerstandsfähigkeit von Paketverlusten durch kurzes Trennen eines Kabels; das Audio sollte bei verlorenen Paketen von 1–2 ms Dauer nicht glitchen; falls dies der Fall ist, erhöhen Sie die Puffergröße leicht (bis zu 4 ms).
  • Ein häufiger Fehler ist das Überladen der Switch-CPU mit PTP-Nachrichten an einem schlecht konfigurierten Port; Verwenden Sie Switch QoS, um PTP zu priorisieren.

Schritt 6: Dokumentieren Sie Ihre Konfiguration

Die IP-, PTP-Rolle, Stream-SDP- und Switch-Port-Konfiguration jedes Geräts aufzeichnen. Dies ist von unschätzbarem Wert, wenn eine Komponente ausfällt und ersetzt werden muss. Ohne Dokumentation ist es fast unmöglich, ein großes AES67-Netzwerk von Grund auf neu aufzubauen.

Häufige Fallstricke - und wie man sie vermeidet

  • PTP-Taktungskonflikte: Das Ausführen mehrerer PTP-Domänen im selben Netzwerk (z. B. Filmsystem mit Domäne 0, während eine Live-Soundkonsole Domäne 1 verwendet) kann zu Verwirrung führen.
  • IGMP-Schnüffel nicht aktiviert: Ohne sie überflutet Multicast-Audio jeden Switch-Port, was zu Paketverlust und unnötigem Laden führt.
  • Fehlkonfigurierte QoS: Wenn PTP hinter einem FTP-Datenverkehr verzögert wird, driftet die Synchronisation. Verwenden Sie strenge Prioritätswarteschlangen (DSCP 46 für PTP, DSCP 34 oder 36 für RTP-Audio).
  • Jumbo-Rahmeninkongruenz: Wenn der Switch Jumbo-Frames unterstützt, der Absender jedoch nicht, erhalten Sie möglicherweise eine Fragmentierung.
  • Ignorieren von Netzwerk-Jitter: Selbst bei perfektem PTP müssen RTP-Jitterpuffer so eingestellt sein, dass sie den Netzwerk-Jitter absorbieren.

Vergleich mit anderen AoIP-Standards

AES67 ist kein Produkt, sondern ein Brückenstandard. Dante dominiert den installierten AV-Markt und unterstützt AES67 als Sekundärmodus. RAVENNA ist in der Sendung beliebt und nutzt bereits AES67 als nativen Audiotransport. Livewire+ (von Wheatstone) basiert auf AES67. Q-LAN Der Hauptunterschied: In einer Multi-Vendor-Umgebung stellt AES67 sicher, dass alle die gleiche Sprache sprechen.

Wenn Sie die niedrigste Latenz (sub-0,25 ms) benötigen, haben proprietäre Systeme immer noch einen Vorteil, aber für 99% der professionellen Nutzung sind die 1 ms von AES67 mehr als ausreichend.

Die Zukunft von AES67

Die Audio Engineering Society entwickelt den Standard weiter. AES67-2022 hat Unterstützung für 32-Bit-Float hinzugefügt, redundante Stream-Handhabung geklärt und das PTP-Profil aktualisiert, um sich an IEEE 1588-2019 anzupassen. Media Networking Alliance Da SMPTE ST 2110 über Live-Events und Gotteshäuser hinausgeht, bleibt AES67 das Audio-Rückgrat. Für jeden Ingenieur, der heute ein vernetztes Audiosystem entwickelt, ist AES67 nicht nur ein Nice-to-have, sondern die sicherste Option für langfristige Kompatibilität.

Um tiefer zu tauchen, konsultieren Sie den Beamten AES67-Norm (AES67-2018/R2023), RTP RFC (RFC 3550), und die IEEE 1588-2008-StandardPraktische Anleitungen von Audinat und RAVENNA Mit einem soliden Verständnis der AES67-Architektur und -Protokolle können Sie ein Audionetzwerk entwerfen, das sowohl hochperformant als auch wirklich offen ist.