Was ist AES67?

Definition und Revisionskontext

AES67 trägt offiziell den Titel „AES standard for audio applications of networks – High-performance streaming audio-over-IP interoperability“ (AES-Standard für Audioanwendungen in Netzwerken – Interoperabilität für hochperformantes Streaming-Audio über IP). Die Audio Engineering Society veröffentlichte die erste Ausgabe im Jahr 2013 und gab die Revision AES67-2018 heraus, nachdem die Praxis in der Branche Mehrdeutigkeiten und Integrationsdetails aufgedeckt hatte, die eine klarere Behandlung erforderten.

Der Standard erschafft kein einzelnes geschlossenes Ökosystem. Er definiert einen technischen Treffpunkt, an dem Produkte verschiedener Hersteller Echtzeit-Audio austauschen können, sofern jedes Produkt das erforderliche Profil implementiert und der Systemintegrator das gemeinsame Netzwerk korrekt konfiguriert. Konformität ist daher ein Ausgangspunkt – kein Versprechen, dass jede optionale Funktion oder Verwaltungsfunktion automatisch funktioniert.

Für Beschaffung und Planung sollten Sie die verwendete Ausgabe zitieren und die Konformitätserklärung des Herstellers prüfen. AES67-2018 ist die Revision, auf die die meisten aktuellen Beschaffungsdokumente verweisen; dennoch sollten Teams den AES-Standards-Katalog vor der Festlegung einer Spezifikation auf Änderungen, Berichtigungen (Corrigenda) oder neuere Ausgaben prüfen.

Der Standard definiert Interoperabilität auf ausgewählten Schichten. Er standardisiert nicht jedes betriebliche Verhalten, das ein Anwender sieht.

Das Interoperabilitätsproblem, das AES67 löst

Vor AES67 löste jede Audio-über-IP-Plattform ähnliche Probleme auf ihre eigene Weise. Ein Dante-Netzwerk, ein RAVENNA-Netzwerk, ein Livewire-System oder eine Q-LAN-Installation konnte innerhalb der eigenen Produktfamilie hervorragendes Echtzeit-Audio liefern, doch direktes herstellerübergreifendes Routing erforderte oft Bridges, Konvertierungshardware oder manuelle Behelfslösungen.

Diese Fragmentierung schuf kommerzielle und betriebliche Risiken. Eine Anlage konnte für Routing, Taktgebung, Steuerung und Support von einem einzigen Ökosystem abhängig werden. Eine Erweiterung des Systems bedeutete, vor der Bewertung von Akustik, Workflow oder Preis zuerst die Protokollkompatibilität zu prüfen. Bestehende Technik ließ sich schwerer weiterverwenden, sobald eine neue Plattform einzog.

AES67 adressiert dieses Problem, indem es einen gemeinsamen Interoperabilitätspfad für den Audiotransport spezifiziert. Es ermöglicht einem nativen Ökosystem, ausgewählte Streams in einer Form bereitzustellen, die ein anderes AES67-fähiges Ökosystem empfangen kann. Deshalb wird AES67 oft als Brücke beschrieben: Es beseitigt nicht die Unterschiede zwischen Plattformen, macht aber kontrollierte Übergänge zwischen ihnen möglich.

Grundlagen von Audio über IP

Ein AoIP-System wandelt abgetastetes Audio in zeitstempelmarkierte Pakete um, sendet diese Pakete über eine Ethernet- und IP-Infrastruktur und rekonstruiert am Empfänger ein durchgehendes Audiosignal. Schwierig ist nicht das Verschieben von Bytes, sondern das Bewahren von Abtast-Timing, Kanalbeziehung und Wiedergabekontinuität, während das Paketnetz mit anderem Datenverkehr geteilt wird.

AES67 setzt ein gemanagtes Netzwerk voraus, das Echtzeit-Medien von gewöhnlichen Daten trennen kann. Netzwerk-Switches benötigen ausreichende Pufferung, Multicast-Kontrolle und Verkehrspriorisierung. Router können Streams zwischen Subnetzen transportieren, wenn das Design Multicast-Routing oder Unicast-Flows unterstützt, doch jede Netzgrenze bringt zusätzliche Konfigurations- und Monitoring-Anforderungen mit sich.

Der Medientakt ist vom Pakettakt getrennt. PTP richtet die Gerätezeit aus, während die Audio-Abtastrate den Medientakt definiert. Ein Empfänger muss sowohl die korrekte Abtastphase als auch einen stabilen Strom von Samples zurückgewinnen. Paketverluste, übermäßiger Jitter oder ein instabiler Takt können Aussetzer verursachen, selbst wenn die durchschnittliche Netzwerkbandbreite mehr als ausreichend ist.

Betrachten Sie das Netzwerkdesign als Teil des Audiosystems, nicht als unterstützende Infrastruktur. VLANs, QoS, PTP-Domänen, Multicast-Querier und Switch-Pufferrichtungen müssen gemeinsam validiert werden. Für kritische Programmpfade sollten Sie außerdem den eingeschränkten Betrieb bei Störungen, den Alarmweg und die Wiederanlaufzeit nach einem Ausfall definieren.

• Die Abtastung wandelt analoges Audio mit einer definierten Rate in diskrete Zahlenwerte um.
• Die Paketierung ergänzt Sequenz-, Zeitstempel- und Nutzdateninformationen, damit Empfänger den Stream rekonstruieren können.
• Pufferung fängt normale Netzwerkschwankungen ab, erhöht aber die Ende-zu-Ende-Latenz.
• Die Synchronisierung hält unabhängige Geräte an einer gemeinsamen Zeitreferenz ausgerichtet.

PTPv2, RTP und SDP

AES67 nutzt das Precision Time Protocol nach IEEE 1588-2008, üblicherweise PTPv2 genannt, um eine gemeinsame Zeitreferenz zu verteilen. PTP-Nachrichten ermöglichen es Geräten, Zeitstempel zu vergleichen und Netzwerklaufzeiten zu korrigieren. In Audiosystemen erlaubt die entstehende Zeitbasis Sendern und Empfängern, Samples auf einer gemeinsamen Zeitachse zu platzieren, statt sich allein auf die Frequenz des lokalen Oszillators zu verlassen.

Das Real-time Transport Protocol, definiert in RFC 3550, trägt die Audio-Nutzdaten. RTP liefert Sequenznummern und Zeitstempel, mit denen Empfänger fehlende oder falsch sortierte Pakete erkennen und die vorgesehene Wiedergabezeit rekonstruieren können. Das RTP Control Protocol kann Empfangsstatistiken liefern, wobei die Control- und Monitoring-Entscheidungen je nach Produkt variieren.

Das Session Description Protocol beschreibt den Stream, bevor er empfangen wird. Ein SDP-Dokument identifiziert Medientyp, Adresse, Port, Nutzdatenformat, Paketzeit, Kanalzuordnung und weitere Parameter. In einigen Systemen wird SDP direkt ausgetauscht, in anderen von einer Discovery- oder Verwaltungsschicht übergeben. Da AES67 kein universelles Geräte-Steuerungsprotokoll definiert, kann der Umgang mit SDP zwischen Implementierungen unterschiedlich sein.

PTP, RTP und SDP sind Standards, die AES67 verwendet. Sie sind keine optionalen Marketing-Labels.

QoS, PCM und Multicast-Verhalten

AES67 verwendet lineares PCM-Audio, damit Empfänger für die Interoperabilität keinen herstellerspezifischen Codec benötigen. Die gängigen Nutzdatenformen sind 16-Bit- und 24-Bit-PCM, oft durch RTP-Payload-Typen wie L16 und L24 beschrieben. Sender und Empfänger müssen sich auf Abtastrate, Paketzeit, Payload-Typ, Kanalzahl und Kanalreihenfolge einigen.

Quality of Service ist wichtig, weil Audiopakete verzögerungsempfindlich, aber nicht zwingend bandbreitenintensiv sind. DSCP-Markierungen und Warteschlangenbehandlung geben PTP- und RTP-Verkehr Vorrang vor Dateiübertragungen, Backups und allgemeinen Office-Daten. Ein VLAN kann helfen, Medienverkehr zu trennen, doch eine VLAN-Trennung allein ersetzt weder ein sauberes Warteschlangendesign noch Monitoring.

Multicast ermöglicht es einem Sender, einen Stream an mehrere Empfänger zu verteilen, ohne den Verkehr für jeden Endpunkt zu vervielfältigen. Es bringt aber auch Risiken: Fehlkonfiguriertes IGMP Snooping, fehlende Querier oder versehentliches Flooding können das gesamte Netzwerk stören. Größere Installationen sollten Multicast-Adressbereiche, Querier-Platzierung, Gruppenlimits und PTP-Domänen vor der Inbetriebnahme planen.

Nach dem Going Live benötigen Paketverlust, Jitter, PTP-Offset, IGMP-Zustand und Switch-Warteschlangen eine kontinuierliche Beobachtung. Viele Interoperabilitätsprobleme zeigen sich nicht als vollständige Stille, sondern als gelegentliche Aussetzer, vertauschte linke und rechte Kanäle, ausbleibende Wiederherstellung nach einem Neustart oder als Anomalien, die nur unter höherer Last auftreten. Beobachtbarkeit sollte zusammen mit dem Audiopfad geplant werden.

• Reservieren Sie Kapazität und Warteschlangen-Budgets für Medienverkehr.
• Verwenden Sie einen dokumentierten Multicast-Adressplan.
• Prüfen Sie die PTP-Domänen- und Prioritätseinstellungen auf allen Netzwerk-Switches.
• Überwachen Sie nach der Inbetriebnahme Paketverluste, Jitter, Taktversatz und IGMP-Zustand.

Was AES67 nicht definiert

AES67 schreibt kein einziges automatisches Geräte-Discovery-System vor. Einige Produkte nutzen SAP-Ankündigungen, einige mDNS oder Bonjour, andere verlassen sich auf einen nativen Controller oder ein Orchestrierungswerkzeug eines Drittanbieters. Ein Gerät kann AES67-fähig sein und trotzdem einen manuellen SDP-Austausch oder Hersteller-Software für den Verbindungsaufbau erfordern.

Er definiert ebenso wenig ein universelles Verbindungsverwaltungsmodell, eine vorgeschriebene Benutzeroberfläche oder eine vollständige Sicherheitsarchitektur. Routing-Berechtigungen, Namenskonventionen, Firmware-Updates, Zugriffskontrolle und Monitoring-APIs bleiben produktspezifisch. Das ist ein Grund, warum AES67-Interoperabilität oft am besten funktioniert, wenn eine Controller- oder Verwaltungsschicht oberhalb des Audiotransports die Endpunkte koordinieren kann.

Redundanz ist eine weitere wichtige Grenze. AES67 definiert die Streaming- und Synchronisierungsschichten, nicht jedoch die nahtlose Paketduplizierung oder Umschaltung. Systeme, die hitless Redundanz benötigen, ergänzen üblicherweise ein Netzwerk-Redundanzschema aus der umgebenden Architektur, etwa Dual-Links mit einem medienspezifischen Schutzverfahren; das genaue Verhalten hängt von den Produkten und dem Netzwerkdesign ab.

Schließlich garantiert AES67 keine Interoperabilität, nur weil ein Logo auf einem Datenblatt steht. Die Implementierung muss weiterhin kompatible Parameter aushandeln, das erforderliche Nutzdatenformat unterstützen und sich unter den erwarteten PTP- und Netzwerkbedingungen korrekt verhalten.

Interoperabilität von Dante, RAVENNA und AES67

Dante ist die proprietäre Audionetzwerk-Technologie von Audinate. Die Dante-AES67-Interoperabilität erscheint typischerweise als Modus oder Konfiguration, die ausgewählte Dante-Flows Audio mit anderen AES67-Geräten austauschen lässt. Native Dante-Erkennung, -Routing, -Steuerung und -Verwaltung bleiben Teil des Dante-Ökosystems, sodass eine AES67-Verbindung neben einer Control-Ebene bestehen kann, die weiterhin Dante Controller oder ein anderes Audinate-Werkzeug erfordert.

RAVENNA ist eine offene Technologieplattform auf Basis standardisierter IP-Protokolle und stark an AES67 und SMPTE ST 2110-30 angelehnt. Sie kann zusätzliche Profile, Formate, Kanalzahlen, Synchronisierungsoptionen und Redundanzmodelle über den minimalen AES67-Interoperabilitätsvertrag hinaus tragen. AES67 ist daher eine verbreitete Schicht innerhalb einer breiteren RAVENNA-Installation, keine vollständige Beschreibung jeder RAVENNA-Fähigkeit.

Hybride Designs sind verbreitet. Eine Anlage kann ein natives Dante-System für Stageboxes, Verstärker und Pulte betreiben und gleichzeitig AES67 nutzen, um einen Broadcast-Kern, ein RAVENNA-Produktionssystem oder einen bestimmten Prozessor eines Drittanbieters anzubinden. Der Integrationsplan sollte festlegen, welche Endpunkte nativ sind, welche im Interoperabilitätsmodus laufen, wo SDP ausgetauscht wird und wer die Takt- und Multicast-Richtlinie verantwortet.

Der fragileste Teil ist oft nicht, ob Audio gesendet werden kann, sondern wie die Grenze gepflegt wird. Ob beide Seiten sich nach einem Firmware-Update, einem Geräteneustart, einem Wechsel des Clock-Masters oder einem Netzwerkausfall wieder verbinden; ob Alarme an einem Ort zusammenlaufen; und ob es ein klares Wartungsverfahren gibt – all das muss früh im Projekt definiert werden.

Der Interoperabilitätsmodus ist eine Systemdesign-Entscheidung. Er beseitigt nicht die Unterschiede nativer Funktionen.

Leitfaden für die Inbetriebnahme

Beginnen Sie mit einem schriftlichen Signal- und Taktplan. Listen Sie jeden Stream mit Richtung, Abtastrate, Paketzeit, Kanalzahl, Multicast-Gruppe, Quelladresse, Empfänger und Fallback-Pfad auf. Entscheiden Sie, ob das Netzwerk für jede Verkehrsklasse Unicast oder Multicast verwendet, und definieren Sie, wie SDP übermittelt und gespeichert wird.

Erstellen Sie einen PTP-Domänenplan, bevor Sie Endpunkte hinzufügen. Bestätigen Sie, welche Geräte Grandmaster sein können, wie Boundary- oder Transparent-Clocks behandelt werden, was geschieht, wenn der bevorzugte Grandmaster ausfällt, und ob das Netzwerk eine stabile Holdover-Strategie besitzt. Testen Sie die PTP-Performance mit derselben Switch-Konfiguration und Verkehrslast, die im Betrieb zu erwarten ist.

Testen Sie anschließend Interoperabilität als System, nicht als Produktdemonstration. Bestätigen Sie Kanalzuordnung, nominale Verstärkung, Sample-Ausrichtung, Stream-Wiederherstellung nach einem Link-Ereignis, Multicast-Join- und -Leave-Verhalten sowie die Sichtbarkeit in der Verwaltung. Beziehen Sie Randfälle ein wie Firmware-Abweichungen, einen neu gestarteten Grandmaster, einen abgezogenen Empfänger und einen überlasteten Uplink.

Die Inbetriebnahme sollte dauerhafte Nachweise hinterlassen: Switch-Konfigurationen, PTP-Logs, Stream-Aufzeichnungen, Testergebnisse und Verantwortlichkeiten für künftige Änderungen. AES67 vereinfacht den Transportvertrag, hebt aber nicht die Notwendigkeit professioneller Netzwerkdisziplin auf.

SoundNet-AES67-Modullösungen

Den Standard zu verstehen ist das eine, ein Produkt zuverlässig AES67 sprechen zu lassen das andere. Die YW-Series-OEM-Module von SoundNet bündeln eine komplette, in der Produktion erprobte AES67-Implementierung — PTPv2-Taktung, RTP-Audioübertragung und Device-Discovery — in einbettbarer Hardware. Hersteller professioneller Audiotechnik können so ihren Produkten Netzwerkaudio hinzufügen, ohne den Stack von Grund auf selbst zu entwickeln. Die Familie reicht vom kompakten 4×4-Modul YW04d bis zum YWRG128 Mini-PCI-Modul mit bis zu 128×128 Kanälen bei 48, 96 oder 192 kHz.

Um die Module herum steht eine Toolchain für den gesamten Workflow: der lizenzfreie AES67 LINK Controller für Routing und Konfiguration, die AES67 Virtual Soundcard, die einen PC in ein 64×64-Endgerät verwandelt, das PoE-gespeiste AES67 Panel für die Raumsteuerung und der Open-Source-Stream Monitor zur Prüfung von Multicast-Streams im Live-Netzwerk.

• Vollständiger AES67-Stack auf dem Modul: Synchronisation, Transport und Discovery übernimmt das Modul, nicht Ihre Firmware-Entwicklung
• Skalierbar von 4×4 bis 128×128 Kanälen über I2S/TDM-Schnittstellen bei 48/96/192 kHz
• Optionales On-Module-DSP mit PEQ, Filtern, Delay, Noise Gate und Feedback-Unterdrückung
• Ein Integrationsaufwand für die gesamte Familie, vom kompakten Endgerät bis zum High-Density-Transport
• Tooling für marktreife Produkte: LINK Controller, VSC, Panel und Stream Monitor decken Konfiguration, Routing und Monitoring ab

Anwendungen und häufige Missverständnisse

AES67 wird in Broadcast-Anlagen, Gotteshäusern, Konferenzzentren, Stadien, Veranstaltungsorten, Aufnahmestudios und großen Campus-Installationen eingesetzt. Es ist besonders nützlich, wenn Geräte mehrerer Hersteller Audio gemeinsam nutzen müssen, eine bestehende AoIP-Infrastruktur an einen neuen Produktionskern angebunden werden soll oder ein standardbasierter Transport für langfristige Wartbarkeit gefordert ist.

Ein Missverständnis ist, dass AES67 bedeutete, jedes AES67-Gerät ließe sich auf dieselbe Weise steuern. In der Praxis kann Audio fließen, während Erkennung, Routing, Beschriftungen und Monitoring getrennt bleiben. Ein weiteres Missverständnis ist, dass AES67 eine Qualitätsstufe oder ein Codec sei. Es ist ein Interoperabilitätsrahmen; die Audioqualität hängt von Quelle, Sample-Format, Taktgebung und Netzwerkverhalten ab.

Ein drittes Missverständnis ist, dass AES67 und ST 2110-30 austauschbare Namen für denselben Standard seien. Sie sind eng verwandt, doch AES67 ist ein Audio-Interoperabilitätsstandard der AES, während ST 2110-30 eine eingeschränkte Audiokomponente der breiteren SMPTE-Suite Professional Media over IP ist. Manche Fachdokumente schreiben ST2110 ohne Leerzeichen, wenn die Familie gemeint ist. Die Unterscheidung spielt eine Rolle, wenn Broadcast-Workflows, NMOS-Steuerung, PTP-Profile und Konformitätsstufen spezifiziert werden.

Schließlich ist AES67 kein Knopf, der jede Kompatibilitätsfrage automatisch löst. Der Umfang der Produktunterstützung, verfügbare Optionen, Lizenzierung, Firmware-Stand, Netzwerkdesign und betriebliche Verfahren beeinflussen alle das Ergebnis. Grenzen klar zu dokumentieren und Ende-zu-Ende-Abnahmetests durchzuführen ist zuverlässiger als das Vertrauen auf Logos oder Marketingaussagen.