AES67

Was regelt der Standard AES67 — und was bedeutet „AES67-fähig" auf einem Datenblatt wirklich für die Planung?

AES67 ist der Standard, über den verschiedene Systeme für Netzwerk-Audio miteinander Ton austauschen. Man kauft ihn nicht und entscheidet sich auch nicht für ihn wie für eine Plattform — ein Gerät erfüllt ihn oder erfüllt ihn nicht. Auf dem Datenblatt steht er als „AES67-fähig", und dieses Wort beantwortet genau eine Frage: Kann das Gerät Tonströme mit Geräten austauschen, die einer anderen Welt angehören — etwa ein Dante-Prozessor mit einem Rundfunk-Zuspieler? Alles Weitere, von der Gerätesuche bis zur Verwaltung, liegt außerhalb des Standards, und genau dort beginnt die Planungsarbeit.

Es gibt mehrere Systeme, die Ton über das Netzwerkkabel schicken, und jedes spricht seine eigene Sprache. AES67 ist die vereinbarte gemeinsame Sprache dazwischen — so wie sich zwei Menschen mit verschiedenen Muttersprachen auf Englisch verständigen. Das klappt für das Wesentliche, aber eben nur dafür: Feinheiten und Komfortfunktionen bleiben in der jeweiligen Muttersprache. Für Dich heißt das: Zwei Geräte mit diesem Stichwort auf dem Datenblatt können grundsätzlich zusammenarbeiten, aber jemand muss die Verbindung von Hand einrichten und vorher prüfen, ob sie im konkreten Fall funktioniert.

Das zugrunde liegende Problem

Netzwerk-Audio ist mehrfach erfunden worden. Dante, RAVENNA, Livewire, Q-LAN und WheatNet-IP lösen alle dieselbe Aufgabe — Tonkanäle unkomprimiert und zeitsynchron über Ethernet — und lösten sie jahrelang so, dass Geräte verschiedener Welten einander schlicht nicht verstanden. Wer Geräte zweier Hersteller verbinden wollte, brauchte Wandlerkästen oder blieb in einer Welt.

Die Audio Engineering Society setzte deshalb Ende 2010 eine Arbeitsgruppe unter dem Vorsitz des Medienetzwerk-Beraters Kevin Gross an; deren Projekt mündete im September 2013 in den Standard AES67. Sein Ansatz ist bewusst bescheiden: Er erfindet kein neues Verfahren, er legt fest, welchen gemeinsamen Kern die bestehenden Verfahren beherrschen müssen, damit ein Tonstrom die Grenze zwischen zwei Welten überqueren kann. Seither ist der Standard mehrfach überarbeitet worden, zuletzt in der Fassung 2023.

Was der Standard regelt

AES67 deckt sechs Bereiche ab: die Synchronisation, die Kennzeichnung des Medientakts, den Netzwerktransport, die Kodierung des Tons, die Beschreibung einer Sitzung und den Verbindungsaufbau. Hinter den sechs Begriffen stehen drei Festlegungen, die man für die Planung kennen sollte.

Eine gemeinsame Uhr. Alle Geräte stellen ihre Uhr nach dem Precision Time Protocol in der Version 2 (IEEE 1588-2008); wie das arbeitet, erklärt der Eintrag Word Clock und PTP. Festgelegt ist dabei auch die Zeitdomäne: AES67 arbeitet in der PTP-Domäne 0. Das klingt nach einer Fußnote und entscheidet in gemischten Anlagen darüber, welche Geräteverbünde sich überhaupt gleichzeitig koppeln lassen.

Ein gemeinsames Tonformat. Der Ton läuft als unkomprimiertes PCM über das Echtzeit-Transportprotokoll RTP, das jedem Paket einen Zeitstempel mitgibt. Pflicht für jedes Gerät sind 48 kHz bei 16 oder 24 Bit mit einer Paketzeit von 1 Millisekunde — das ist das Austauschformat, auf das sich alle verlassen können. Kürzere Paketzeiten bis 125 Mikrosekunden und weitere Abtastraten wie 44,1 oder 96 kHz sind zulässig, aber freiwillig.

Eine gemeinsame Priorisierung. Damit Takt und Ton in einem gemischten Netz nicht hinter einem Dateitransfer warten, ordnet AES67 den Verkehr in QoS-Klassen: Taktpakete erhalten die höchste Stufe, Tonpakete die zweite, alles Übrige läuft ohne Vorrang. Die Verteilung an mehrere Empfänger läuft über Multicast und IGMP, wobei jeder Tonstrom eine eigene Multicast-Adresse mit genau einem Sender bekommt.

Was der Standard bewusst nicht regelt

Der Satz, der über Erfolg und Grenze von AES67 zugleich entscheidet, steht im Standard selbst: Gerätesuche, Konfiguration und Verwaltung sind nicht Teil der Festlegung. Für die Suche nennt der Standard mehrere mögliche Verfahren, schreibt aber keines vor; für Multicast-Verbindungen ist gar kein Verwaltungsprotokoll definiert, für Punkt-zu-Punkt-Verbindungen dient das Sitzungsprotokoll SIP aus der IP-Telefonie.

Warum ist das so entscheidend? Weil damit niemand zuständig ist, wenn zwei fremde Geräte einander finden sollen. Ein reines AES67-Gerät meldet sich nicht von selbst in der Übersichtssoftware der jeweils anderen Welt; jemand muss die Adresse des Stroms kennen, ihn von Hand abonnieren und die Taktführung prüfen. Genau diese Lücke füllen die Hersteller-Plattformen mit ihren eigenen Werkzeugen — deshalb bestehen sie neben dem Standard fort, und AES67 verbindet sie, statt sie abzulösen. Redundanz regelt der Standard ebenfalls nicht: Wer zwei Welten koppelt, koppelt sie im Zweifel nur über das primäre Netz.

Für die Planung folgt daraus eine einfache Rollenverteilung: Innerhalb einer Anlage wählt man eine Plattform, die Suche, Patchen und Verwaltung mitbringt. AES67 ist das Werkzeug für die Übergänge — dort, wo eine zweite Welt unvermeidlich ist, etwa weil ein vorhandenes Gerät nur die eine spricht.

RAVENNA: die offene Umsetzung aus dem Rundfunk

RAVENNA ist keine Alternative zu AES67, sondern eine der Welten, die er verbindet — und zugleich seine wichtigste Vorlage. Entwickelt hat es das Münchner Entwicklungshaus ALC NetworX, das zum 1. Januar 2024 im Audiohersteller Lawo aufgegangen ist; öffentlich vorgestellt wurde RAVENNA 2010 auf der Rundfunkmesse IBC. Lawo vertritt die Position, dass AES67 den zuvor für RAVENNA festgelegten Definitionen folgte und der Standard damit praktisch eingebaut ist; unabhängig davon belegt ist, dass RAVENNA vor AES67 entstand und AES67-konform arbeitet.

Zwei Eigenschaften unterscheiden RAVENNA von Dante, dem anderen verbreiteten Vertreter der IP-basierten Welten:

Es ist offen. Die Unterlagen zur Umsetzung sind frei zugänglich, und jeder Hersteller darf eigene Umsetzungen bauen, ohne bei einem Unternehmen ein Modul zu lizenzieren. Lawo bietet fertige IP-Pakete und die Logo-Nutzung an, dazu gibt es mehrere Anbieter fertiger Module und kostenfreie virtuelle Soundkarten für den Rechner. Die Geräteauswahl hängt damit nicht an der Lizenzpolitik eines einzelnen Anbieters — bei Dante liegt genau diese Entscheidung bei einem einzigen Unternehmen.

Es lebt im Rundfunk. Die Einsatzfelder, mit denen RAVENNA beworben wird, heißen Rundfunkhaus, Ü-Wagen, Veranstaltungsort und Studioverbindung; unter den über 50 Partnerunternehmen stehen Namen wie Genelec, Merging Technologies, Riedel und Ross Video — durchweg Studio- und Broadcast-Technik. Auch die Nähe zum Fernsehstandard SMPTE ST 2110, der AES67 als Audiotransport übernommen hat, gehört in dieses Bild. Im Wohnbereich begegnet RAVENNA einem fast nur, wenn Geräte aus der Studiowelt den Weg ins Haus finden — etwa Abhörmonitore oder D/A-Wandler von Herstellern, die im Studiogeschäft zu Hause sind. Eine Wohnbereichs-Plattform mit Gerätesuche und Bedienoberfläche für den Endkunden ist RAVENNA nicht und will es auch nicht sein.

Für die AVITECT-Planung heißt das: RAVENNA wählt man für ein Wohnprojekt gar nicht erst aus — es ist eine Eigenschaft, die manche Geräte mitbringen. Steht sie auf dem Datenblatt, ist das die gute Nachricht — die Anbindung an andere Welten läuft dann über genau den Standard, den diese Seite beschreibt, ohne zusätzliche Lizenzabhängigkeit.

Voraussetzungen

Das Netz muss können, was jedes Netzwerk-Audio-System verlangt — durchgehend Gigabit, sauberes Multicast, Priorisierung im gemischten Betrieb; im Zusammenhang erklärt das die Seite Audio over IP. Drei Punkte kommen bei AES67 hinzu.

Die Taktfrage zuerst. Vor jeder Kopplung zweier Welten steht die Entscheidung, welches Gerät die gemeinsame Uhr führt und in welcher PTP-Domäne. Da AES67 die Domäne 0 festlegt, kann etwa eine Dante-Umgebung ihren AES67-Modus immer nur für eine ihrer Domänen gleichzeitig einschalten.

Jemand muss patchen. Da der Standard keine Gerätesuche vorschreibt, braucht die Inbetriebnahme ein Werkzeug oder ein Verfahren, mit dem Ströme angelegt und abonniert werden — je nach beteiligten Geräten ist das die Software der einen Plattform, die des Herstellers oder Handarbeit mit Adresslisten. Diese Zuständigkeit gehört vor der Bestellung geklärt, nicht danach.

Die Übergabestelle gehört dokumentiert. Eine Brücke zwischen zwei Welten steht in keiner der beiden Übersichtssoftwares vollständig drin. Adressen, Formate und Taktführung der AES67-Ströme müssen deshalb schriftlich festgehalten werden, sonst ist die Anlage beim ersten Gerätetausch nicht mehr nachvollziehbar.

Abgrenzung

Gegen Dante. Dante ist ein Produkt mit Lizenz, Werkzeugkette und Gerätesuche; AES67 ist die herstellerneutrale Vereinbarung, über die Dante-Geräte mit Fremdgeräten sprechen. Wie schmal diese Brücke im Dante-Fall ausfällt — Multicast-Austausch bei weiterhin nativem Transport unter Dante-Geräten —, steht auf der Dante-Seite.

Gegen AVB und Milan. AES67 setzt auf der IP-Ebene auf und kommt durch jedes ordentliche Gigabit-Netz; AVB reserviert Bandbreite unterhalb davon auf der Ethernet-Ebene und verlangt AVB-fähige Switches auf dem ganzen Weg. Eine direkte Kopplung gibt es deshalb nicht; wer eine Milan-Anlage mit einer AES67-Welt verbinden will, braucht ein Gerät, das in beiden zu Hause ist.

Gegen SMPTE ST 2110. ST 2110 ist der Standard der professionellen Fernsehwelt für Bild und Ton über IP; sein Audioteil übernimmt AES67. Wer aus der Videoproduktion kommt, begegnet AES67 deshalb als Bestandteil von ST 2110 — im Wohnbereich spielt dieser Überbau keine Rolle, gemanagte Videoverteilung im Haus läuft über andere Verfahren (AV over IP).

Grenzen

Der kleinste gemeinsame Nenner ist klein. Über die Brücke gehen Tonkanäle, Takt und Zeitstempel — nicht die Komfortfunktionen der Plattformen. Gerätesuche, zentrale Verwaltung, Presets und Redundanz enden an der Systemgrenze. Eine gemischte Anlage ist deshalb immer aufwendiger zu betreiben als eine einheitliche, auch wenn beide Hälften denselben Standard erfüllen.

Das Stichwort auf dem Datenblatt ersetzt keine Prüfung. Ob zwei konkrete Geräte zusammenspielen, hängt an Details, die das Wort „AES67-fähig" nicht verrät: unterstützte Suchverfahren, Multicast gegen Unicast, Adressbereiche, Formatstufen jenseits der Pflicht, Firmwarestand. Verlässlich ist erst die dokumentierte Kombination aus beiden Geräten mit ihren Firmwareständen.

Für die reine Wohnanlage ist AES67 selten der Ausgangspunkt. Wer eine Anlage neu plant, wählt eine Plattform und bleibt in ihr; die Brücke wird erst gebraucht, wenn eine zweite Welt dazukommt. Ein Planungsziel „alles über AES67" hätte die Betriebsnachteile der gemischten Anlage ohne ihren Anlass.

Verknüpfte Inhalte

Wie sich die vier Welten des Netzwerk-Audios zueinander verhalten und was das Netz dafür mitbringen muss, ordnet die Wissensseite Audio over IP — sie ist die Voraussetzung für alles hier. Eigene Seiten haben Dante und AVB und Milan. Für die gemeinsame Uhr ist Word Clock und PTP der Anschlusspunkt, für die Verteilung an viele Empfänger Multicast und IGMP, für die Priorisierung QoS und für die Segmentierung VLAN und Subnetz. Den klassischen digitalen Punkt-zu-Punkt-Weg beschreibt AES3.

Quellen

Regelungsumfang und Revisionsstände von AES67 stammen aus dem geprüften Quellenapparat der Wissensseite Audio over IP vom 6. August 2026; die frühere Übersichtsseite des Standards ist nach dem Umbau der AES-Website nicht mehr erreichbar, das AES-Archiv bestätigt am 19. August 2026 den Kommentaraufruf zur Revision vom Dezember 2023. Die neue Produktseite im Standards-Store der AES, gefunden im Review-Lauf am 21. August 2026, bestätigt Titel, Fassung 2023 und Regelungsumfang; der Standardtext selbst ist kostenpflichtig und bleibt uneingesehen. Die technischen Detailangaben (PTP-Profil, Tonformate, Paketzeiten, QoS-Klassen, Discovery-Lücke) sind über eine Sekundärquelle erfasst und im Text entsprechend gekennzeichnet. Alle Angaben zu RAVENNA — Herkunft bei ALC NetworX, Aufgehen in Lawo zum 1. Januar 2024, Vorstellung 2010, Offenheit, Partnerkreis und das Verhältnis zu AES67 und ST 2110 — sind am 19. August 2026 an den Seiten des RAVENNA-Netzwerks (Lawo) gelesen; die dortige Aussage, AES67 sei den RAVENNA-Definitionen gefolgt, ist die Position des Herstellers. Das Verhalten der Dante-Brücke und die feste PTP-Domäne 0 sind in der Audinate-Dokumentation belegt. Firmwareabhängige Aussagen gelten nur für den jeweils genannten Stand.