Understanding Aes67: A Comprehensive Guide for Audio Professionals
Table of Contents
Was ist AES67 und warum es für Audio-Profis wichtig ist
In der professionellen Audioindustrie hat der Wechsel von analog zu digital bemerkenswerte Treue und Flexibilität gebracht, aber mit ihm kam eine neue Herausforderung: Interoperabilität. Verschiedene Hersteller entwickelten ihre eigenen Audio-over-IP-Lösungen (AoIP) und schufen isolierte Ökosysteme, die nicht miteinander kommunizieren konnten. AES67 wurde entwickelt, um diese Barrieren abzubauen. Dieser offene Standard, der 2013 von der Audio Engineering Society veröffentlicht wurde, definiert einen gemeinsamen Satz von Protokollen und Transportmechanismen, die es jedem AES67-kompatiblen Gerät ermöglichen, Audio mit jedem anderen AES67-Gerät zu entdecken, zu verbinden und zu streamen - unabhängig vom Anbieter. Für Audioprofis, die in Live-Sound, Broadcast, Aufnahmestudios oder installiertem Sound arbeiten, ist das Verständnis von AES67 unerlässlich für den Aufbau flexibler, kostengünstiger und zukunftssicherer Netzwerke. Dieser Artikel bietet einen detaillierten Einblick in AES67, seine technischen Grundlagen, praktische Implementierungstipps und wie es mit anderen beliebten AoIP-Standards verglichen wird.
Vor AES67 war Audio über IP eine fragmentierte Landschaft. Dante, Ravenna, AVB, LiveWire und Q-LAN hatten jeweils ihre eigenen Transportmechanismen, Synchronisationsmethoden und Erkennungsprotokolle. Um sie miteinander zu verbinden, waren teure Gateways oder proprietäre Konverter erforderlich. AES67 entstand als Universalübersetzer, die ein Mindestprofil definiert, das jeder Anbieter umsetzen kann, das bestehende Systeme nicht ersetzt, sondern eine Brücke zwischen ihnen bildet. Heute ist AES67 weit verbreitet und bildet die Grundlage für Broadcast-IP-Standards wie SMPTE ST 2110.
Der Kernzweck von AES67
AES67, früher bekannt als AES-Standard für Audioanwendungen von Netzwerken – Hochleistungs-Streaming-Audio-over-IP-Interoperabilität, ist kein vollwertiges Netzwerkprotokoll an sich. Stattdessen legt es eine Reihe von Anforderungen fest, die bestehende Protokolle erfüllen müssen, um Interoperabilität zu gewährleisten. Der Standard konzentriert sich auf drei Schlüsselbereiche: Transport, Synchronisation und Stream Discovery. Durch die Anordnung gemeinsamer Profile für RTP (Real-Time Transport Protocol), PTP (Precision Time Protocol) und SAP (Session Announcement Protocol) stellt AES67 sicher, dass Geräte verschiedener Hersteller hochwertige Audiostreams mit niedriger Latenz ohne proprietäre Gateways austauschen können.
Der Standard unterstützt bis zu 2 Kanäle pro Stream in seiner Basisimplementierung, aber mehrere Streams können kombiniert werden, um höhere Kanalzahlen zu unterstützen. Er arbeitet über Standard-Ethernet-Netzwerke mit IPv4 oder IPv6, wodurch er auf der vorhandenen IT-Infrastruktur zugänglich ist. Abtastraten von 48 kHz und 96 kHz werden mit Bittiefen von 16, 20 oder 24 Bit unterstützt. Die Latenz ist konfigurierbar, reicht jedoch typischerweise von 1 Millisekunde bis zu mehreren Millisekunden, was für die meisten professionellen Anwendungen geeignet ist.
Ein entscheidender Aspekt ist, dass AES67 keine spezifischen Netzwerktopologie- oder Switch-Anforderungen vorschreibt, sondern Parameter definiert, die das Netzwerk unterstützen muss: Multicast-Routing, PTP-Zeitverteilung und QoS-Markierungen für Audio-Datenverkehr. Diese Flexibilität ermöglicht es AES67, über Standard-Gigabit-Ethernet-Netzwerke zu laufen, obwohl spezialisierte Switches mit PTP-Unterstützung und niedrigem Jitter für große oder kritische Anwendungen empfohlen werden.
Die wichtigsten Features im Detail
Interoperabilität über Anbieter hinweg
Das Hauptmerkmal von AES67 ist die Fähigkeit, proprietäre Systeme zu überbrücken. Beispielsweise kann ein Dante-basiertes Mischpult Audio von einem mit Ravenna verbundenen Mikrofonvorverstärker empfangen, wenn beide AES67-kompatibel sind. Dadurch entfällt die Notwendigkeit mehrerer Netzwerkadapter oder Konvertierungsboxen, was das Systemdesign vereinfacht und die Kosten reduziert. Interoperabilität wird durch die strikte Einhaltung der im Standard definierten Medientaktung, Paketierung und Synchronisationsparameter erreicht. In der Praxis bedeutet dies, dass ein Gerät von Yamaha (Dante) Audio zu einem Gerät von Lawo (Ravenna) streamen kann, ohne dass eine spezielle Konfiguration über die Aktivierung des AES67-Modus und die Einstellung korrekter PTP-Parameter hinausgeht.
Leistung bei niedriger Latenz
AES67 ist für Echtzeit-Audio konzipiert. Es unterstützt sowohl Unicast- als auch Multicast-Streaming, wobei Multicast die bevorzugte Methode für die Punkt-zu-Mehrpunkt-Verteilung ist. Der Standard erlaubt Latenzzeiten von nur 1 Millisekunde (im 1-Millisekunden-Paketzeitmodus) für 48 kHz-Streams, obwohl praktische Implementierungen oft 4-Millisekunden- oder 8-Millisekunden-Paketzeiten verwenden, um den Netzwerk-Overhead und die Zuverlässigkeit auszugleichen. Diese niedrige Latenz ist entscheidend für Live-Sound-Verstärkung, In-Ear-Überwachung und Broadcast-Anwendungen, bei denen Verzögerungen nicht wahrnehmbar sein müssen. Bei 4 ms-Paketzeit bleibt die End-to-End-Latenz typischerweise unter 10 ms, wenn Netzwerkausbreitung, Pufferung und Verarbeitung eingeschlossen sind.
Präzisionssynchronisation mit PTP
Alle AES67-Netzwerke verlassen sich auf IEEE 1588â2008 Precision Time Protocol (PTP), um Audiouhren über Geräte hinweg zu synchronisieren. PTP liefert Mikrosekunden-Genauigkeit, um sicherzustellen, dass alle Geräte Audio zur gleichen Zeit abtasten. Dies eliminiert die Taktdrift und vermeidet hörbare Artefakte wie Pops, Klicks oder Phasenabbruch. Der Standard schreibt ein PTP-Profil vor (oft das Standardprofil oder das AES67-spezifische Profil) mit einem Synchronisationsintervall von 1 Sekunde und einem Ansageintervall von 2 Sekunden. Die richtige PTP-Konfiguration ist die häufigste Ursache von Problemen in AES67-Bereitstellungen, so dass Netzwerkingenieure den PTP-Verkehr priorisieren und eine genaue Zeitverteilung sicherstellen müssen.
Für missionskritische Installationen kann die Verwendung einer GPS-disziplinierten Grandmaster-Uhr oder einer Grenzuhr im Netzwerkschalter die Stabilität dramatisch verbessern.
Skalierbarkeit für jedes Größennetzwerk
AES67 skaliert von einfachen Punkt-zu-Punkt-Verbindungen bis hin zu groÃen Broadcast-Anlagen mit Hunderten von Streams. Da es Standard-IP-Multicast verwendet, kann die Bandbreite mit IGMP-Snooping und einer korrekten Switch-Konfiguration verwaltet werden. Der Standard schreibt keine maximale Anzahl von Geräten oder Streams vor, aber die Netzwerkkapazität muss entsprechend geplant werden. Mit 1 Gbps Ethernet können Hunderte von gleichzeitigen 48 kHz / 24-Bit-Stereostreams problemlos flieÃen. Höhere Geschwindigkeiten (10 Gbps oder mehr) ermöglichen noch gröÃere Systeme, wodurch AES67 für Stadien, Kongresszentren und Netzwerk-Audio-Backbones geeignet ist.
Zum Beispiel könnte eine groÃe Broadcast-Einrichtung 200+ Streams gleichzeitig mit einem 10 Gbps-Backbone mit redundanten Switches ausführen.
Warum AES67 für moderne Audio-Workflows von entscheidender Bedeutung ist
In der heutigen Audioindustrie dominiert kein einziger Hersteller alle Produktkategorien. Ein Sendestudio könnte eine Lawo-Konsole (Ravenna-basiert), drahtlose Shure-Mikrofone (Dante) und Genelec-Monitore (AES67 über Dante oder Ravenna) verwenden. Ohne AES67 würde die Integration dieser Systeme proprietäre Adapter oder teure Konvertierungshardware erfordern. AES67 beseitigt diese Reibung, so dass Audioprofis das beste Werkzeug für jeden Auftrag auswählen können, ohne sich um Kompatibilität zu sorgen.
Darüber hinaus unterstützt AES67 qualitativ hochwertiges unkomprimiertes Audio, das den Anforderungen kritischer Hörumgebungen entspricht. Für Rundfunkanbieter ermöglicht der Standard eine nahtlose Integration mit ST 2110 (dem SMPTE-Standard für professionelle Medien über IP), da AES67 die Audiotransportschicht für ST 2110-30 und ST 2110-31 bildet. Dies macht AES67 zu einer grundlegenden Technologie für IP-basierte Sendeeinrichtungen, die von SDI zu IP wechseln. In Live-Sound ermöglicht AES67 Reisesystemen die Integration von Leihgeräten verschiedener Anbieter, ohne das gesamte Netzwerk neu zu konfigurieren.
Die Einführung von AES67 ist auch zukunftssicher für Investitionen. Da es sich um einen offenen Standard handelt, der nicht an einen einzigen Anbieter gebunden ist, bleibt die heute gekaufte Ausrüstung mit zukünftigen Systemen kompatibel, die AES67 unterstützen. Dies reduziert die langfristigen Kosten und die Komplexität, insbesondere in Großanlagen, in denen die Technologieaktualisierungszyklen lang sind. Darüber hinaus verfügt AES67 über einen klaren Upgrade-Pfad zu AES X192 (derzeit in Entwicklung), der höhere Kanaldichten und verbesserte Redundanz verspricht.
Die technische Grundlage von AES67
Transport: RTP und Payload-Typen
AES67 verwendet RTP, um Audiodaten über UDP/IP-Netzwerke zu übertragen. Der Standard erfordert die Unterstützung für den L24-Nutzlasttyp (24-Bit-lineare PCM) und ermöglicht sowohl 16-Bit- als auch 20-Bit-Audio. Jedes RTP-Paket enthält eine feste Anzahl von Audio-Samples, die durch die Paketzeit (1 ms, 4 ms oder 8 ms) bestimmt werden. Der RTP-Header enthält einen Zeitstempel, der von der PTP-Uhr abgeleitet wird, so dass Empfänger das Audiosignal auch in nicht deterministischen Netzwerken genau rekonstruieren können. RTP bietet auch Sequenznummern, die bei der Erkennung von Paketverlust und Lieferung auÃerhalb der Ordnung helfen.
Aus Redundanzgründen unterstützen einige Implementierungen FEC (Forward Error Correction), aber dies ist nicht Teil der Kernspezifikation AES67.
Synchronisation: PTP und Clock Domains
Die PTP-GroÃmeisteruhr stellt die Zeitbasis für alle Geräte bereit. Es kann sich um ein dediziertes Hardwaregerät (z. B. eine PTP-GroÃmeisteruhr von Meinberg oder ein Ethernet-Switch mit Boundary-Clock-Funktionalität) oder eine Softwareimplementierung (mit geringerer Präzision) handeln. Alle AES67-Endpunkte müssen in der Lage sein, mit der PTP-Domäne zu synchronisieren und Audiouhren zu erzeugen, die auf die PTP-Zeit gesperrt sind. Der Standard ermöglicht Redundanz, indem er mehrere PTP-GroÃmeister in einer Hot-Standby-Konfiguration unterstützt. In der Praxis verwenden die meisten AES67-Bereitstellungen einen einzigen GroÃmeister, oft das Mischpult oder eine dedizierte Taktquelle.
Die PTP-Domänennummer sollte im gesamten Netzwerk konsistent sein; Domäne 0 ist üblich, aber einige Hersteller empfehlen Domäne 1 für AES67.
Stream Discovery: SAP und Session Description Protocol
Um Streams im Netzwerk zu finden, verwenden AES67-Geräte SAP, um RTP-Sitzungen anzukündigen. Jede Ankündigung enthält eine Session Description Protocol (SDP)-Datei, die die Stream-Parameter beschreibt: Quell-IP, Ziel-Multicast-Adresse, RTP-Nutzlasttyp, Samplerate, Anzahl der Kanäle und PTP-Domäne. Geräte hören auf diese Ankündigungen und können dann die gewünschten Streams abonnieren. Einige Implementierungen unterstützen auch Unicast-Streaming für Punkt-zu-Punkt-Verbindungen, bei denen Multicast nicht verfügbar oder gewünscht ist. SAP verwendet die Multicast-Adresse 239.255.0.1 und den UDP-Port 9875.
In gröÃeren Netzwerken muss IGMP-Snooping so konfiguriert sein, dass SAP-Ankündigungen nicht alle Ports überfluten.
AES67 vs. andere AoIP-Protokolle
Mehrere AoIP-Protokolle dominieren den professionellen Audiomarkt. Es ist wichtig für das Systemdesign zu verstehen, wie AES67 mit ihnen zusammenhängt.
| Protokoll | Verhältnis zu AES67 | Hauptunterschiede |
|---|---|---|
| Dante | Audinate Dante ist ein proprietäres System, bietet aber seit Dante Firmware 4.0 AES67-Unterstützung in vielen Produkten. Dante-Geräte können so konfiguriert werden, dass sie AES67-Streams ausgeben, was die Interoperabilität mit Nicht-Dante-Geräten ermöglicht. | Dante verwendet seine eigene Taktung und Erkennung (Dante Controller). Der AES67-Modus kann einige Dante-spezifische Funktionen verlieren (wie Unicast-Abonnements oder Kanalzahlen über 2). |
| Ravenna | Ravenna wurde von Lawo und ALC Network entwickelt und basiert auf AES67 und erweitert es um zusätzliche Funktionen wie redundante Streams, höhere Kanalzahlen und flexibles Routing. Ravenna-Geräte sind AES67-konform. | Ravenna bietet ein erweitertes Netzwerkmanagement und unterstützt bis zu 256 Kanäle pro Stream, während die AES67-Basis auf 2 Kanäle pro Stream begrenzt ist (obwohl mehrere Streams gebündelt werden können). |
| AVB/TSN | IEEE 1722 AVB (Audio Video Bridging) und sein Nachfolger TSN (Time-Sensitive Networking) bieten deterministischen Transport mit niedrigem Jitter. AES67 kann über AVB-Netzwerke laufen, wenn es richtig konfiguriert ist, aber AVB benötigt spezielle Switches und Endpunkte. | AVB/TSN garantiert Bandbreite und Latenz, während AES67 auf IP-Netzwerke mit bestem Aufwand mit PTP-Synchronisation setzt. AVB ist komplexer und teurer, bietet aber eine höhere Zuverlässigkeit für kritische Anwendungen. |
| LiveWire | LiveWire wird von Axia und Telos verwendet und ist ein proprietäres AoIP-System, das im Rundfunk beliebt ist. Einige LiveWire-Geräte unterstützen AES67, aber nicht alle. Interoperabilität erfordert oft ein Gateway. | LiveWire verfügt über ein eigenes Steuerungs- und Überwachungssystem, das bei Verwendung des AES67-Modus möglicherweise nicht verfügbar ist. |
Für die meisten Audioprofis fungiert AES67 als universelle Brücke. Es ermöglicht einer Dante-Konsole, mit einer Ravenna-E/A-Box oder einem AVB-basierten Mikrofonarray zu kommunizieren, um Audio an eine Broadcast-Konsole zu senden, die nur AES67 unterstützt. Der Schlüssel ist, dass die Geräte ordnungsgemäß konfiguriert sind und die Netzwerkinfrastruktur die Anforderungen für PTP und Multicast erfüllt.
Es ist auch erwähnenswert, dass viele moderne AoIP-Geräte mehrere Modi unterstützen. So kann ein einzelner Switch sowohl Dante/AES67- als auch Ravenna/AES67-Streams gleichzeitig übertragen, solange sie die gleiche PTP-Domäne und kompatible Paketzeiten verwenden. Diese Flexibilität macht AES67 zu einer hervorragenden Wahl für heterogene Umgebungen.
Implementierung von AES67 in Ihrem Setup
Die erfolgreiche Implementierung von AES67 erfordert eine sorgfältige Planung und Aufmerksamkeit für das Netzwerkdesign. Befolgen Sie diese Schritte, um AES67 in Ihr Audiosystem zu integrieren.
Schritt 1: Gerätekompatibilität überprüfen
Ãberprüfen Sie, ob Ihr vorhandenes Gerät AES67 unterstützt. Viele moderne Dante-Geräte haben eine Firmware-Einstellung, um den AES67-Modus zu aktivieren. Ravenna-Geräte sind standardmäÃig AES67-fähig. Für ältere Geräte benötigen Sie möglicherweise eine dedizierte AES67-Konverterbox (z. B. von DirectOut, Digigram oder Neutrik). Dokumentieren Sie die unterstützten Sampleraten, Paketzeiten und PTP-Profile jedes Geräts.
Einige Geräte erfordern möglicherweise eine Lizenz- oder Firmware-Aktualisierung, um die AES67-Funktionalität freizuschalten.
Schritt 2: Entwerfen Sie das Netzwerk
AES67 funktioniert am besten in einem dedizierten oder segmentierten Audionetzwerk mit Gigabit-Ethernet-Switches mit geringer Latenz und Unterstützung für IGMP-Snooping, PTP-Transparent-Clock oder Boundary-Clock und QoS-Priorisierung. Empfohlene Switches sind die Cisco Catalyst 3850-Serie, die Netgear M4300-Serie oder die Luminex GigaCore-Serie. Vermeiden Sie Consumer-Grade-Switches, da sie Multicast möglicherweise nicht effizient handhaben oder übermäßigen Jitter hinzufügen.
Bei PTP ist ein Gerät als Grandmaster-Uhr zu bezeichnen, wobei es sich um ein Gerät mit einem stabilen Oszillator handeln sollte (vorzugsweise ein PTP-Hardware-Großmeister oder ein Mischpult mit hochpräziser interner Uhr), alle anderen Geräte müssen als Slave-Uhren konfiguriert sein. Es ist sicherzustellen, dass PTP-Nachrichten im Netzwerk höchste Priorität erhalten (DSCP 46 oder 56 für PTP-Ereignisnachrichten).
Schritt 3: PTP konfigurieren
Stellen Sie die PTP-Domänennummer konsistent für alle Geräte (üblicherweise Domäne 0 oder Domäne 1 für AES67) ein. Konfigurieren Sie die Einstellungen der Grandmaster-Uhr â verwenden Sie das AES67-Profil, falls verfügbar. Für die meisten Einsätze wird ein zweistufiger Uhrenmodus für die Genauigkeit empfohlen. Sobald PTP ausgeführt wird, überprüfen Sie, ob alle Slaves innerhalb weniger Mikrosekunden eine Synchronisierung mit dem Grandmaster melden. Viele Geräte haben eine Status-LED oder Web-Schnittstelle, die eine PTP-Sperre anzeigt.
Verwenden Sie Wireshark oder ein PTP-Ãberwachungstool, um die Uhrgenauigkeit des Grandmasters und den Offset der Slaves zu überprüfen.
Schritt 4: Streams einrichten
Mit der Software des Geräts (z. B. Dante Controller, Ravenna Network Manager oder herstellerspezifische Apps) Sender und Empfänger erstellen. Jeder Stream muss eine eindeutige Multicast-Adresse haben (im Bereich 239.192.0.0/14 ist typisch für AES67). Konfigurieren Sie die gleiche Samplerate, Bittiefe und Paketzeit an beiden Enden. Für Interoperabilität werden Paketzeiten von 1 ms, 4 ms oder 8 ms unterstützt - aber alle Geräte müssen die gleiche Paketzeit für einen bestimmten Stream verwenden. 4 ms ist eine gute Balance, da sie weitgehend kompatibel ist und eine akzeptable Latenz bietet. Wenn ein Gerät nur 1 ms unterstützt, stellen Sie sicher, dass das Netzwerk die höhere Paketrate verarbeiten kann, ohne Frames fallen zu lassen.
Schritt 5: Testen und Validieren
Nach der Konfiguration ist zu überprüfen, ob Audio korrekt fließt. Auf Störungen, Ausfälle oder Synchronisationsfehler achten. Verwenden Sie Netzwerkdiagnosetools wie WireShark mit AES67-Dissektor oder dedizierte AoIP-Testtools (z. B. Audio Precision APx500 mit AoIP-Option oder N. V. L. L. A. B. Tools). Prüfen Sie, ob der PTP-Offset unter 1 Mikrosekunde bleibt und der Paketverlust weniger als 0,01 % beträgt. Führen Sie Lasttests mit der erwarteten Anzahl von Streams durch. Bei Broadcast-Installationen überprüfen Sie gegebenenfalls auch die Einhaltung von ST 2110-30.
Schritt 6: Pflegen und Überwachen
Sobald das System in Betrieb ist, laufende Überwachung einrichten, SNMP verwenden, um Switch-Ports, PTP-Status und Stream-Abonnement zu verfolgen, redundante PTP-Großmeister implementieren, falls für kritische Installationen erforderlich, Gerätefirmware aktualisieren, wenn die Hersteller die AES67-Kompatibilität und -Leistung verbessern, Netzwerktopologie, IP-Adressen, Multicast-Gruppen und PTP-Einstellungen für zukünftige Referenzen dokumentieren.
Gemeinsame Herausforderungen und wie man sie überwindet
Selbst bei sorgfältiger Planung können AES67-Einsätze auf Probleme stoßen. Hier sind die häufigsten Probleme und ihre Lösungen.
- PTP-Synchronisationsfehler: Verursacht durch unsachgemäße Grandmaster-Auswahl, übermäßige Netzwerksprünge oder Switches, die keine PTP-transparente Uhr unterstützen Lösung: Verwenden Sie Switches mit Hardware-PTP-Unterstützung, minimieren Sie Hops und stellen Sie sicher, dass der Grandmaster eine stabile Zeitquelle hat (z. B. GPS).
- Audio-Aussetzer oder Verzerrung: Häufig aufgrund von Netzwerkstaus, falschen QoS-Einstellungen oder falsch abgestimmten Paketzeiten. Lösung: Priorisieren Sie den Audioverkehr (DSCP 56 für RTP), isolieren Sie das Audionetzwerk vom allgemeinen Datenverkehr und bestätigen Sie, dass alle Geräte die gleiche Paketzeit verwenden. Überprüfen Sie den Paketverlust mithilfe von Statistiken vom Switch oder Gerät.
- Das Gerät entdeckt keine Streams: SAP-Ankündigungen können durch IGMP-Snooping oder Firewalls blockiert werden. Lösung: IGMP-Abfrager auf dem Switch aktivieren, sicherstellen, dass Multicast erlaubt ist, und überprüfen, ob die SAP-Zieladresse (239.255.0.1) routbar ist.
- Latenz im Laufe der Zeit erhöhen: Die Lösung: Qualität der PTP-Schlosse überprüfen und sicherstellen, dass die Geräte nicht auf eine frei laufende Uhr zurückfallen. Einige Geräte erfordern möglicherweise eine periodische PTP-Rekonfiguration. Verwenden Sie einen dedizierten Großmeister mit GPS-Disziplin für langfristige Stabilität.
- Interoperabilität zwischen bestimmten Geräten: Einige Kombinationen können subtile Parameterfehlanpassungen aufweisen (z. B. RTP-Nutzlast Typ 96 vs. benutzerdefiniert). Lösung: Überprüfen Sie die Herstellerdokumentation auf bekannte Kompatibilitätsmodi und kontaktieren Sie den Support, falls erforderlich. Manchmal kann die Verwendung eines Drittanbieter-Controllers (wie Mergings Aneman) beim Aushandeln von Parametern helfen.
- Hochwasser im Multicast-Bereich: Ohne IGMP-Snooping können Multicast-Streams alle Switch-Ports überfluten, was zu Bandbreitenproblemen führt Lösung: IGMP-Snooping aktivieren und einen Abfrager konfigurieren Verwendung von Switch-Ports, um die Multicast-Verteilung auf nur die Geräte zu beschränken, die den Stream benötigen.
Die Zukunft von AES67
AES67 entwickelt sich weiter. Die AES hat Updates für den Standard veröffentlicht und bleibt ein aktives Arbeitselement. Eine wichtige Entwicklung ist die Integration mit SMPTE ST 2110 für die Broadcast-Produktion, die AES67 als Audiotransport verwendet. Da mehr Broadcast-Einrichtungen auf IP-basierte Workflows umsteigen, wird AES67 eine zentrale Rolle spielen. Darüber hinaus arbeitet die Audio Engineering Society an AES X192, einem Standard der nächsten Generation, der höhere Kanaldichte, flexiblere Stream-Formate und verbesserte Redundanz adressieren kann.
Ein weiterer Trend ist die Konvergenz von AES67 mit AVB/TSN. Einige Hersteller bieten Geräte an, die sowohl im AES67- als auch im AVB-Modus arbeiten können, so dass die Benutzer zwischen kostengünstigem IP-Netzwerk (AES67) oder garantiertem deterministischem Transport (AVB) wählen können.
Schließlich hat die Open-Source-Community AES67 angenommen. Projekte wie PipeWire und Jack Audio Connection Kit haben AES67-Unterstützung, was Linux-basierten Audio-Workstations die Verbindung zu professionellen AoIP-Netzwerken ermöglicht. Dies senkt die Eintrittsbarriere für kleine Studios und unabhängige Audio-Profis. Darüber hinaus bieten Anbieter zunehmend softwaredefinierte AES67-Endpunkte an, die auf Standardservern laufen können, wodurch die Hardwarekosten gesenkt werden.
Mit der Entwicklung der Branche in Richtung All-IP-Infrastrukturen wird die Rolle von AES67 als Interoperabilitätsschicht nur noch wachsen. Die Einführung von AES67 in neuen Segmenten wie Automobil-Audio, Intercom-Systeme und verteiltes Audio erweitert die Reichweite des Standards über traditionelles Pro-Audio hinaus.
Schlussfolgerung
AES67 hat die Art und Weise, wie Audioprofis über vernetztes Audio denken, grundlegend verändert. Durch die Bereitstellung einer gemeinsamen Interoperabilitätsschicht können Geräte verschiedener Hersteller nahtlos zusammenarbeiten, Systemkosten und Komplexität reduzieren und gleichzeitig die für professionelle Anwendungen erforderliche hohe Leistung beibehalten. Ob Sie eine Sendeanlage, eine Live-Sound-Tour oder eine feste Installation entwerfen, AES67 bietet Ihnen die Werkzeuge, um flexiblere und zuverlässigere Audionetzwerke zu bauen. Mit der richtigen Planung, Konfiguration und Netzwerkinfrastruktur kann AES67 ein starker Verbündeter in Ihrem Audio-Toolkit sein.
Für weitere Informationen konsultieren Sie die offizielle AES67-Spezifikation, die von der Audiotechnik-Gesellschaftund erkunden Sie Implementierungshandbücher von Anbietern wie Audinat und ALC-NetzPraktische Tipps zum Netzwerkdesign finden Sie in der Broadcast Bridge Für einen tiefen Einblick in die PTP-Synchronisation beziehen sich auf die IEEE 1588-Spezifikation und Ressourcen von MeinbergDie heutige Einführung von AES67 bedeutet, in einen offenen Standard zu investieren, der neben der Audioindustrie weiter wächst und sich weiterentwickelt.