Inhalt anzeigen
- Tiefe
- Fortgeschritten
Audio over IP
Was ist Audio over IP — und was muss ein Netzwerk können, damit Dante, AES67, RAVENNA oder Milan darüber laufen?
Audio over IP heißt: Tonkanäle laufen als Datenpakete durch dasselbe Ethernet, das im Haus auch Rechner und Fernseher verbindet. Es gibt darum keine „AoIP-Kabelgattung" und keinen eigenen Stecker — was es gibt, sind drei Ebenen, die man sauber auseinanderhalten muss: die Plattform (Dante, AES67, RAVENNA, AVB/Milan), den Transport (Ethernet, in aller Regel Gigabit) und das Medium (Cat 6A, Glasfaser). Wer eine Anlage plant, entscheidet auf allen drei Ebenen getrennt — und nur die erste steht auf dem Datenblatt des Verstärkers.
Früher lief für jeden Lautsprecherweg ein eigenes Kabel vom Gerät zum Ziel. Heute kann man alle Tonwege gemeinsam über die Netzwerkverkabelung schicken, die ohnehin im Haus liegt — mehr als hundert Kanäle über eine einzige Leitung. Das Kabel dafür ist ein ganz normales Netzwerkkabel; besonders ist nur, was die Geräte damit anstellen. Für Dich heißt das vor allem: Was an Netzwerk im Rohbau liegt, entscheidet später mit darüber, wie viel Ton wohin kann.
Warum das keine Kabelfrage ist
Der häufigste Denkfehler beim Thema beginnt beim Einkauf. Auf dem Datenblatt eines Prozessors steht „Dante", also sucht jemand nach einem Dante-Kabel. Es gibt keines. Dante, AES67, RAVENNA und Milan sind logische Dienste; physikalisch liegt darunter jedes Mal gewöhnliches Ethernet. Dieselbe Cat-6A-Leitung überträgt heute Netzwerk-Audio und morgen einen Dateitransfer, ohne dass sich an ihr etwas ändert.
Der Unterschied liegt in dem, was die Geräte an den Enden tun — und darin, was die Geräte dazwischen können müssen. Genau deshalb ist die saubere Dreiteilung so nützlich:
| Ebene | Beispiel | Wer legt sie fest |
|---|---|---|
| Plattform | Dante, AES67, RAVENNA, AVB/Milan | die Audiogeräte |
| Transport | 100BASE-TX, 1000BASE-T, Ethernet über SFP | Gerät und Switch gemeinsam |
| Medium | Cat 6A, OM4-Faser | die Verkabelungsplanung |
Diese Trennung ist nicht akademisch. Sie beantwortet in der Praxis drei Fragen, die sonst durcheinandergeraten: Ob zwei Geräte miteinander sprechen können, entscheidet die Plattform. Wie viele Kanäle über eine Leitung passen, entscheidet der Transport. Wie weit die Leitung reichen darf, entscheidet das Medium. Ein Gerät mit Dante-Modul wird nicht dadurch kompatibel, dass man ein teureres Kabel verlegt — und eine zu lange Kupferstrecke wird nicht dadurch kürzer, dass beide Seiten dieselbe Plattform sprechen.
Vier Welten über demselben Netz
AES67 ist der Standard, kein Produkt. Die Audio Engineering Society gründete Ende 2010 die Task Group SC-02-12-H unter Vorsitz des Medienetzwerk-Beraters Kevin Gross; deren Projekt AES-X192 mündete im September 2013 in AES67, seither mehrfach überarbeitet, zuletzt 2023. Der Standard regelt sechs Bereiche: Synchronisation, Kennzeichnung des Medientakts, Netzwerktransport, Kodierung und Streaming, Beschreibung der Sitzung und Verbindungsaufbau. Was er ausdrücklich nicht regelt, ist die Gerätesuche, die Konfiguration und die Verwaltung einer Anlage — und das erklärt, warum es AES67 gibt und die Hersteller-Plattformen trotzdem nicht verschwinden.
Dante ist die verbreitetste dieser Plattformen. Sie stammt aus einem Forschungsteam am australischen Institut NICTA in Sydney, das Aidan Williams 2006 als Audinate ausgründete. Dante ist proprietär und umfasst mehr als den reinen Transport: Geräte finden sich selbst, die Verkabelung wird in einer Software gepatcht statt am Rack, und die Taktführung läuft automatisch. Dieser Komfort ist der eigentliche Grund für die Verbreitung.
RAVENNA kommt von ALC NetworX, heute Teil von Lawo, und geht den umgekehrten Weg: offen auf bestehenden Standards aufgebaut, von Haus aus AES67- und SMPTE-ST-2110-konform. Im Rundfunk ist es stark, im Wohnbereich begegnet es einem selten.
AVB und Milan stehen technisch abseits der übrigen drei. AVB ist eine Familie von IEEE-Standards — 802.1AS für die Zeit, 802.1Qat für die Bandbreitenreservierung, 802.1Qav für die Warteschlangen, 802.1BA als Gesamtprofil — und arbeitet auf Ethernet-Ebene statt auf IP-Ebene. Der entscheidende Unterschied für die Planung: Ein AVB-Strom reserviert sich seine Bandbreite im Voraus, und dafür muss jeder Switch auf dem Weg AVB beherrschen. Milan ist das darauf aufsetzende Endgeräteprofil der Avnu Alliance, das die Interoperabilität zwischen Herstellern verbindlich macht; die Spezifikation ist frei verfügbar.
Die gemeinsame Uhr ist der eigentliche Kern
Was diese vier Welten trennt, ist selten die Datenrate — es ist die Zeit. Ein Netzwerk liefert Pakete zuverlässig, aber nicht pünktlich: Jedes nimmt einen etwas anderen Weg und braucht eine etwas andere Dauer. Für einen Dateitransfer ist das gleichgültig, für vierzig Tonkanäle, die gemeinsam ein Klangbild ergeben sollen, nicht. Deshalb führen alle AoIP-Systeme Zeitstempel mit, und alle Geräte stellen ihre Uhr nach derselben Referenz.
Diese Referenz liefert das Precision Time Protocol nach IEEE 1588. Wie es arbeitet und worin es sich von der klassischen Word Clock unterscheidet, steht im Eintrag Word Clock und PTP. Für die Planung zählt vor allem, dass die Profile nicht deckungsgleich sind: Dante setzt in der Vorgabe auf PTPv1 und aktiviert PTPv2 zusätzlich, sobald RTP eingeschaltet ist; AES67 und RAVENNA nutzen PTPv2; AVB und Milan nutzen mit 802.1AS ein eigenes Profil davon. Zwei Geräte, auf deren Datenblatt beide „PTP" steht, synchronisieren also nicht zwangsläufig miteinander.
Aus derselben Zeitlogik folgt die zweite Größe, die man kennen sollte: die eingestellte Verzögerung. Bei Dante liegt der typische Vorgabewert bei 1 Millisekunde, sehr schnelle Geräte wie PCIe-Karten gehen bis auf 150 Mikrosekunden herunter, an 100-Mbit/s-Ports bleibt 1 Millisekunde die Untergrenze. Eingestellt wird der Wert am Empfänger, und wenn Sender und Empfänger unterschiedliche Werte verlangen, gewinnt der höhere. Das ist kein Mangel, sondern der Puffer, der die Laufzeitschwankung des Netzes auffängt — wer ihn zu klein wählt, hört Aussetzer statt weniger Verzögerung.
Was das Netzwerk dafür können muss
Die Anforderungen sind überschaubar, aber sie sind hart. Vier Punkte tauchen in jeder Herstellerdokumentation auf.
Gigabit statt 100 Mbit/s, und zwar überall. Nicht wegen der Datenmenge — ein Kanal mit 24 Bit und 48 kHz ergibt rund 1,2 Mbit/s —, sondern wegen der Zeit. An einem 100-Mbit/s-Port dauert das Senden eines Pakets zehnmal so lange, und diese Zeit landet direkt in der Verzögerung, die eingestellt werden muss.
Priorisierung, sobald anderer Verkehr mitläuft. Audinate nennt für Dante ausdrücklich Switches mit vier Warteschlangen und DiffServ-QoS mit strikter Priorität und schränkt zugleich ein: Auf einem ausschließlich für Dante genutzten Gigabit-Netz ist QoS nicht erforderlich, auf gemischten oder 100-Mbit/s-Netzen dagegen schon. Crestron ordnet für DM NAX konkrete DSCP-Werte zu — CS7 für zeitkritische PTP-Ereignisse, CS6 für übriges PTP, EF für Audio.
Energiesparfunktionen abschaltbar. Energy Efficient Ethernet legt Ports in Ruhephasen schlafen und weckt sie beim nächsten Paket. Das kostet genau die Berechenbarkeit, auf die PTP angewiesen ist. Audinate empfiehlt darum, EEE an allen Ports mit Echtzeit-Audioverkehr abzuschalten — und beim Kauf darauf zu achten, dass der Switch das überhaupt zulässt.
Multicast im Griff behalten. Ein Sender, viele Empfänger: Das ist der Regelfall bei Netzwerk-Audio, und ohne IGMP-Snooping schickt der Switch diese Ströme an alle Ports gleichzeitig. Crestron verlangt für DM NAX IGMPv2-Snooping und mindestens einen IGMPv2-Querier im Netz. Dieselbe Mechanik ist bei der Videoverteilung noch kritischer und ist dort ausführlicher beschrieben — siehe AV over IP.
Wo die Interoperabilität endet
„AES67-fähig" auf zwei Datenblättern heißt nicht, dass zwei Geräte zusammenarbeiten. Der Standard ist als Brücke gebaut, nicht als Ersatz — und die Brücke ist schmaler, als der Begriff vermuten lässt.
Audinate dokumentiert das für Dante ungewöhnlich klar. Im AES67-Modus tauschen Dante-Geräte Multicast-Ströme mit Fremdgeräten aus; untereinander verwenden sie weiterhin immer das native Dante-Transportprotokoll, auch wenn das Audio ursprünglich von einem AES67-Gerät kam. Presets erfassen AES67-Flows nicht. Ältere Gerätegenerationen abonnieren nur im Adressbereich 239.x/16. Und weil AES67 eine feste PTPv2-Domain (0) vorsieht, lässt sich AES67 immer nur für eine Domain gleichzeitig aktivieren.
Für die Praxis heißt das: Eine gemischte Anlage aus zwei Plattformen ist möglich, aber sie ist eine Konstruktion mit benannten Übergangsstellen — kein Zustand, der sich von selbst einstellt. Wer mischen muss, legt vorher fest, welches Gerät die Brücke bildet und welche Domäne den Takt führt.
Häufige Missverständnisse
„Wir streamen doch schon Musik übers Netzwerk — das ist dasselbe." Es ist das Gegenteil. Ein Streaming-System wie Sonos, HEOS oder BluOS schickt eine komprimierte Datei oder einen Datenstrom an ein Gerät, das ihn puffert und dann abspielt; Verzögerungen im Sekundenbereich sind unkritisch, weil der Puffer sie schluckt. Audio over IP überträgt dagegen einzelne Kanäle unkomprimiert und in Echtzeit, mit einer Verzögerung im Bereich von einer Millisekunde, weil am anderen Ende ein Verstärker sitzt, der zusammen mit anderen Verstärkern ein Klangbild erzeugen muss. Das eine ist eine Zuspielung, das andere ersetzt Kabelwege. Beide laufen über dasselbe Netz und stellen an dieses Netz völlig unterschiedliche Anforderungen.
„Ein Netzwerkkabel ist ein Netzwerkkabel." Für die Übertragung stimmt das. Für die Planung nicht ganz: Was zählt, ist die durchgehende Gigabit-Fähigkeit der gesamten Strecke inklusive Dosen, Patchfeldern und Switch-Ports. Eine Anlage, die an einer einzigen alten 100-Mbit/s-Verbindung hängt, zwingt das ganze System auf deren Zeitverhalten.
„Wenn alles über ein Kabel läuft, ist ein Kabelbruch fataler." Der Punkt ist berechtigt, und die Plattformen beantworten ihn unterschiedlich. Dante kennt eine Redundanz über ein zweites, physikalisch getrenntes Netz. AES67 selbst regelt Redundanz nicht — was in gemischten Aufbauten bedeutet, dass die Brücke zwischen den Welten im Zweifel nur über das primäre Netz läuft.
In der Planung
Ein Haus bekommt Musik in acht Räumen, dazu ein Kino mit eigenem Prozessor. Die Verstärker sollen zentral im Technikraum stehen.
Die erste Frage ist keine Produktfrage, sondern eine Konzeptfrage: Was soll zentral erzeugt und was dezentral verstärkt werden — und müssen Räume miteinander synchron spielen können? Solange die Antwort „jeder Raum für sich, Zuspielung aus dem Netz" lautet, reicht ein sauber gebautes Heimnetz mit Streaming-Geräten, und Audio over IP ist gar nicht das Thema. Sobald mehrere Räume gemeinsam ein Klangbild ergeben sollen oder Signalwege dorthin führen, wo kein Audiokabel mehr hinkommt, verschiebt sich die Antwort.
Daraus folgt die Verfahrensfrage, und sie hat drei Teile, die alle zusammen entschieden werden: die Plattform, weil sie festlegt, welche Geräte überhaupt in Frage kommen; die Netztopologie, weil AVB andere Switches verlangt als die IP-basierten Welten; und die Frage, ob der Audioverkehr ein eigenes Netzsegment bekommt. Wer diese drei trennt, hat am Ende eine Plattform, die die vorhandenen Switches nicht können.
Erst danach kommen die Geräte. Und erst an dieser Stelle wird die Verkabelung konkret: Cat 6A zu jedem Endpunkt, Faser mit SFP-Transceivern für die Verbindung zwischen Technikraum und entfernten Verteilern, und ein Leerrohr für das, was heute noch niemand weiß.
Grenzen und Sonderfälle
Der Bestand. Netzwerk-Audio setzt eine strukturierte Verkabelung voraus, die in Bestandsgebäuden oft nur teilweise existiert. Ein einzelner Raum lässt sich mit einer nachgezogenen Leitung erschließen; eine Anlage, die ihre Hauptwege über WLAN nimmt, funktioniert nicht — Funk liefert die gleichmäßige Laufzeit nicht, auf die PTP angewiesen ist.
Lizenz- und Bezugsfragen. Dante ist proprietär; welche Geräte es sprechen, entscheidet nicht der Planer, sondern der Gerätehersteller. Diese Abhängigkeit ist ein realer Nachteil gegenüber den offenen Wegen — dem steht der praktische Vorteil gegenüber, dass die Gerätesuche und das Patchen tatsächlich funktionieren, was AES67 allein nicht leistet.
Firmwareabhängigkeit. Was ein Gerät an AES67-Interoperabilität tatsächlich kann, hängt am Firmwarestand und ändert sich mit ihm. Jede konkrete Kompatibilitätszusage gehört mit Gerät und Firmwarestand dokumentiert, nicht mit dem Plattformnamen allein.
Verknüpfte Inhalte
Wie das Netzwerk im Haus insgesamt aufgebaut wird und warum Verfügbarkeit und gleichmäßige Laufzeit vor Bandbreite kommen, steht auf der Seite Heimnetzwerk-Grundlagen — sie ist die Voraussetzung für alles hier. Die zeitliche Seite vertieft der Eintrag Word Clock und PTP, die klassischen digitalen Punkt-zu-Punkt-Wege die Einträge zu AES3 und S/PDIF. Was für Bild und Ton gemeinsam über dasselbe Netz gilt, behandelt AV over IP. Für die physikalische Seite sind Kabelkategorien, SFP-Transceiver und die Faserklassen OM und OS die Anschlusspunkte; wo die Technik dafür steht, klärt Technikraum für AV-Technik.
Quellen
Umfang und Regelungsbereiche von AES67 stehen im Standard selbst (Erstveröffentlichung 2013, Revisionen bis 2023); die Ergänzungen der Fassung 2018 dokumentiert der AES Standards News Blog. Die Angaben zu Dante — PTPv1 als Vorgabe, Wahl des Leader Clock, Verzögerungswerte von 1 ms bis 150 µs, Verhalten im AES67-Modus und die feste PTPv2-Domain 0 — stammen sämtlich aus den Handbüchern zu Dante Controller und Dante Domain Manager. Die AVB-Standardfamilie ist bei der IEEE definiert, das Endgeräteprofil Milan bei der Avnu Alliance. Die Netzwerkvorgaben für DM NAX, einschließlich der DSCP-Zuordnung und der IGMP-Anforderungen, stehen in Crestrons Dokumentation zum Audio-over-IP-Netzwerkdesign. Herkunft und Gründung von RAVENNA und Audinate sind bei ALC NetworX beziehungsweise Audinate selbst belegt.