Die Evolution von Audio over IP

Audio over IP (AoIP) hat die Art und Weise, wie professionelle Audiosysteme entworfen, eingesetzt und betrieben werden, grundlegend verändert. Durch den Austausch dedizierter analoger oder digitaler Verkabelung durch Standard-Ethernet-Netzwerke ermöglicht AoIP eine größere Flexibilität, Skalierbarkeit und Kosteneffizienz. Unter den verschiedenen AoIP-Standards hat sich AES67 als eine kritische Interoperabilitätsschicht herauskristallisiert, die es Geräten verschiedener Hersteller wie Dante, RAVENNA und Livewire ermöglicht, Audiostreams zu koexistieren und auszutauschen. Das Herzstück von AES67 liegt in der Fähigkeit, sowohl Multicast- als auch Unicast-Streaming zu verwenden, die jeweils für unterschiedliche Betriebsanforderungen geeignet sind. Das Verständnis, wann diese Übertragungsmodi anzuwenden sind, ist für Netzwerkingenieure, Audiosystemintegratoren und Produktionsprofis, die eine zuverlässige, latenzarme Audioverteilung benötigen, unerlässlich.

Was ist AES67?

AES67 ist ein von der Audio Engineering Society entwickelter Standard, der 2013 offiziell als AES67-2013 veröffentlicht und in späteren Überarbeitungen aktualisiert wurde. Er definiert eine Reihe von Anforderungen für leistungsstarkes Audiostreaming über IP-Netzwerke, wobei der Schwerpunkt auf Interoperabilität liegt. Der Standard spezifiziert Audioformate (bis zu 24-Bit-, 48-kHz- oder 96-kHz-Sample-Raten), Paket-Timing, Netzwerksynchronisation und Transportprotokolle. Entscheidend ist, dass AES67 die Verwendung von RTP (Real-Time Transport Protocol) über UDP für Audio-Nutzlasten vorschreibt und sowohl die Bereitstellung von Unicast (Point-to-Point) als auch von Multicast (Point-to-Multipoint) unterstützt. AES67 schreibt zwar kein spezifisches Steuerungs- oder Discovery-Protokoll vor, passt aber an weithin anerkannte Mechanismen wie SAP (Session Announcement Protocol) und RTSP (Real Time Streaming Protocol).

Eine der wichtigsten Stärken von AES67 ist die Anforderung an die Netzwerksynchronisation, die auf dem IEEE 1588 Precision Time Protocol (PTP) beruht, um eine Genauigkeit des Timings unter Mikrosekunden zu erreichen. Dies stellt sicher, dass mehrere Geräte Audio mit einer Ausrichtung auf Sample-Level-Ebene wiedergeben können - eine wichtige Voraussetzung für Live-Soundverstärkung, Broadcast-Mix-Minus und Mehrrauminstallationen. AES67 definiert auch Jitterpuffer und Strategien zur Paketverlustverschleierung, was es praktisch für den Einsatz in verwalteten und nicht verwalteten Netzwerken macht, vorausgesetzt, dass Latenz- und Bandbreitenbeschränkungen richtig konstruiert sind.

Um mehr über die offizielle AES67-Spezifikation zu erfahren, besuchen Sie die Website von AES Standards.

Multicast-Streaming in AES67

Multicast ist ein Eins-zu-viele-Übertragungsverfahren, bei dem ein einzelner Audiostream an eine IP-Multicast-Gruppenadresse gesendet wird. Alle Geräte, die diese Gruppe abonniert haben, erhalten den Stream gleichzeitig. Im Zusammenhang mit AES67 ist Multicast der Standard- und am häufigsten verwendete Modus, da er effizient für große Zielgruppen skaliert. Wenn eine Quelle einen Multicast-Stream sendet, verwendet das Netzwerk Protokolle wie IGMP (Internet Group Management Protocol) und PIM (Protocol Independent Multicast), um Pakete nur in Netzwerksegmente zu replizieren, in denen Abonnenten vorhanden sind. Dies verhindert unnötigen Bandbreitenverbrauch auf Verbindungen, die keine interessierten Empfänger haben.

AES67-Multicast-Streams verwenden typischerweise UDP-Transport- und RTP-Nutzlasten mit einer festen Paketierungszeit (z. B. 1 ms oder 4 ms), der Stream wird durch eine Multicast-IP-Adresse im Bereich 239,0,0,0 bis 239,255.25,2555 für IPv4 und einen entsprechenden UDP-Port identifiziert. Die PTP-Synchronisation stellt sicher, dass alle Empfänger das Audio mit der gleichen Uhr rekonstruieren, wodurch Drift- und Phasenunterschiede eliminiert werden.

Vorteile von Multicast

  • Bandbreiteneffizienz: Mit zunehmender Anzahl von Hörern ist der Bandbreitenverbrauch pro zusätzlichem Empfänger in geteilten Segmenten nahezu Null.
  • Vereinfachtes Source Management: Das Sendegerät sendet einen einzelnen Stream, unabhängig davon, wie viele Ziele ihn benötigen, was die CPU-Auslastung der Quelle reduziert und das Routing rationalisiert.
  • Natürliche Synchronisation: Alle Empfänger erhalten die gleiche RTP-Zeitstempelbasis, wodurch es einfacher wird, mehrere Lautsprecher, Monitore oder Feeds an einem Veranstaltungsort auszurichten.
  • Skalierbarkeit: Geeignet für große Installationen wie Stadien, Kongresszentren oder Sendeanlagen mit Hunderten von Zielen.

Nachteile von Multicast

  • Anforderungen an die Netzinfrastruktur: Switches und Router müssen IGMP-Snooping und Multicast-Routing unterstützen.
  • Sicherheitsherausforderungen: Jedes Gerät im Netzwerk kann sich potenziell einer Multicast-Gruppe anschließen und den Stream empfangen. Verschlüsselung ist nicht Teil des Basis-AES67-Standards, obwohl optionale Methoden oben geschichtet werden können.
  • Begrenzte Fehlerwiederherstellung: Da Multicast UDP verwendet, gibt es keine automatische Weiterübertragung verlorener Pakete.Redundanz beruht auf Netzwerkdesign (z. B. redundante Streams oder Pfaddiversität).

Typische Multicast Use Cases

  • Live Konzert Audio-Verbreitung: Senden des Hauptmixes an Front-of-House, Monitorkonsolen, Aufnahme-Trucks und Broadcast-Mixer gleichzeitig.
  • Infrastruktur des Rundfunkstudios: Verteilen von Programm-Audio von einem Master-Kontrollraum zu mehreren Studios, Edit-Suiten und Übertragungspfade.
  • Große Konferenzsysteme: Bereitstellung von Dolmetschkanälen oder eines gemeinsamen Audio-Feeds für zahlreiche Besprechungsräume oder Bodenboxen.
  • Beschallungs- und Notrufsysteme: Sendeankündigungen über einen campus oder transport-hub mit synchronisierter wiedergabe.

Unicast Streaming in AES67

Unicast stellt eine Eins-zu-eins-Verbindung zwischen einer Quelle und einem einzelnen Empfänger bereit. Die Quelle sendet einen dedizierten Stream mit einer eigenen RTP-Sitzung an die IP-Adresse des jeweiligen Ziels. Obwohl AES67 hauptsächlich auf Multicast für Interoperabilitätstests abzielt, unterstützen viele AES67-kompatible Geräte auch die Unicast-Übertragung für spezialisierte Anwendungen. Unicast kann über UDP (nicht zuverlässig) oder, seltener, über TCP (zuverlässig, aber mit höherer Latenzzeit) implementiert werden.

Bei einer Unicast-Konfiguration benötigt jeder Empfänger einen separaten Stream von der Quelle. Wenn fünf Geräte dasselbe Audio benötigen, müssen fünf identische Unicast-Streams übertragen werden. Dies verbraucht offensichtlich mehr Gesamtnetzwerkbandbreite als Multicast, bietet jedoch in ausgewählten Szenarien deutliche Vorteile.

Vorteile von Unicast

  • Stream-spezifische Anpassung: Die Quelle kann die Qualität, die Samplerate oder die Kanalzuordnung jedes Streams pro Empfänger anpassen. Beispielsweise könnte ein Monitoringenieur einen Stereomix erhalten, während ein Broadcast-Mixer eine 5.1-Surround-Version erhält.
  • Verbesserte Sicherheit: Da Unicast-Streams Punkt-zu-Punkt sind, können nicht autorisierte Geräte den Stream nicht versehentlich erfassen, es sei denn, sie werden explizit angesprochen oder das Netzwerk ist kompromittiert.
  • Einfacheres Netzwerkdesign für kleine Bereitstellungen: In einem Studio mit nur zwei oder drei Geräten kann Unicast die Notwendigkeit einer Multicast-Routing-Konfiguration und eines IGMP-Managements eliminieren.
  • Mögliche Verwendung von TCP für Zuverlässigkeit: In Nicht-Echtzeit-Anwendungen (z. B. Dateiübertragung oder Aufzeichnungssicherung) kann TCP die Paketzustellung sicherstellen, obwohl dies aufgrund von Latenzbeschränkungen nicht typisch für Live-AES67-Audio ist.

Nachteile von Unicast

  • Skalierung der Bandbreite: Jeder zusätzliche Empfänger verbraucht die Bandbreite eines vollen Streams für alle Links von der Quelle zu diesem Empfänger, was den Quell-NIC oder die Uplinks überlasten kann, wenn viele Unicast-Hörer anwesend sind.
  • Höhere Verarbeitungslast der Quelle: Das Sendegerät muss für jeden Unicast-Flow separate RTP-Sitzungen, Zeitstempel und Synchronisation erzeugen und verwalten.
  • Potenzial für Clock Sync Probleme: Wenn jeder Unicast-Stream seinen eigenen PTP-Kontext verwendet, können Empfänger geringfügige Unterschiede im Timing erfahren, es sei denn, die Grandmaster-Uhr ist in allen Streams üblich.

Typische Unicast Use Cases

  • Persönliche Überwachung in Tonstudios: Jeder Musiker erhält einen einzigartigen Kopfhörermix, der aus der gleichen Multi-Track-Quelle stammt, jedoch mit benutzerdefinierten Levels und Effekten.
  • Fernaudiomanagement: Ein Ingenieur wählt sich über eine WAN-Verbindung in ein bestimmtes Gerät ein, um die Einstellungen zu beheben oder anzupassen, wobei ein Unicast-Stream für die Punkt-zu-Punkt-Steuerung verwendet wird.
  • Prüfung oder Kalibrierung des Einzelprodukts: Ein Techniker sendet einen Testton an einen einzelnen Lautsprecher oder Verstärker, ohne andere Geräte im Netzwerk zu beeinträchtigen.
  • Sichere Streams für vertrauliche Kommunikation: Regierungs- oder Unternehmenseinrichtungen können verlangen, dass sensibles Audio nur an einen Endpunkt geliefert wird, wodurch Multicast-Sendungen vermieden werden.

Detaillierter Vergleich: Multicast vs. Unicast in AES67

Die Wahl zwischen Multicast und Unicast hängt von mehreren Faktoren ab, darunter die Anzahl der Empfänger, die Netzwerktopologie, Latenzanforderungen und den administrativen Overhead.

Attribut Multicast Unicast
Bandbreiteneffizienz Hoch für viele Empfänger Niedrig, wenn viele Empfänger
Quelle CPU-Last Niedrig (ein Strom) Erhöht sich linear mit Empfängern
Netzkonfiguration Erfordert IGMP, PIM, sorgfältiges Subnetting Einfach; keine Multicast-Protokolle erforderlich
Synchronisation Alle Empfänger teilen sich einen RTP-Stream und PTP Jeder Stream kann eine unabhängige Synchronisierung haben (sollte aber den gleichen Großmeister verwenden)
Sicherheit/Privatsphäre Niedriger; jeder abonnierte Empfänger kann zuhören Höher; Strom adressiert an bestimmte IP
Latenz Niedrig und konsistent (UDP, keine Weiterleitung) Low if UDP; TCP kann Verzögerung hinzufügen
Fehlerresistenz Keine Weiterleitung; verlassen Sie sich auf FEC oder redundante Streams Kann TCP für Zuverlässigkeit (hohe Latenz) oder UDP mit FEC verwenden

Für einen tieferen Blick auf Multicast-Netzwerkdesign für professionelle Audio, beziehen sich auf die Audinate Artikel über Multicast vs Unicast in Dante (Hinweis: Dante verwendet AES67 im Interoperabilitätsmodus).

Netzwerküberlegungen für AES67 Streaming

Sowohl Multicast- als auch Unicast-AES67-Streams stellen Anforderungen an die zugrunde liegende Netzwerkinfrastruktur.<10 ms), high reliability, and deterministic performance. Key factors include:

Uhrensynchronisation (PTP)

AES67 erfordert IEEE 1588-2008 (PTPv2) für die Taktverteilung. Eine Grandmaster-Uhr wird ausgewählt (oft über den Best Master Clock Algorithm), und alle Geräte synchronisieren sich mit ihr. Das Netzwerk muss PTP-transparente Uhren oder Grenzuhren unterstützen, um die Genauigkeit über Switches hinweg zu gewährleisten.

Servicequalität (QoS)

AES67-Audiopakete müssen gegenüber anderen Netzwerkdatenverkehr priorisiert werden, um Warteschlangenverzögerungen und fallengelassene Pakete zu vermeiden DSCP-Werte (Differentiated Services Code Point): typischerweise EF (Expedited Forwarding, DSCP 46) für Audio-RTP und CS7 für PTP-Ereignisse.

Bandbreitenschätzung

AES67-Streams variieren in ihrer Größe je nach Abtastrate, Bittiefe und Kanalanzahl. Eine 1-ms-Paketisierung bei 48 kHz/24-Bit-Stereo verwendet ungefähr 6 Mbps. Für 96 kHz/24-Bit 8-Kanal erwarten Sie näher an 24 Mbps. Multiplizieren Sie mit der Anzahl der gleichzeitigen Streams (Unicast oder Multicast), um sicherzustellen, dass Ihre Switch-Uplinks und Source-NICs Headroom haben.

Jitterpuffer

Empfänger verwenden Jitterpuffer, um Schwankungen des Netzwerk-Timings zu absorbieren. AES67 empfiehlt Puffer von 1 ms bis 5 ms, abhängig von der Netzwerkqualität. Größere Puffer erhöhen die Latenz, verbessern aber die Widerstandsfähigkeit. Im Unicast kann Jitter je nach Stream unterschiedlich sein, während Multicast-Empfänger eine gemeinsame Pufferabstimmung haben können.

VLANs und Netzwerksegmentierung

Um Audio-Datenverkehr von Datenverkehr zu isolieren, legen Sie AES67-Geräte auf einem dedizierten VLAN. Dies vereinfacht die QoS und reduziert die Interferenz von Sendungen oder großen Dateiübertragungen. Verwenden Sie beim Überspannen mehrerer VLANs Multicast-Routing (PIM), wenn Multicast über Subnetze benötigt wird.

Für einen umfassenden Leitfaden zum AoIP-Netzwerkdesign finden Sie unter AudioScience AoIP Network Design Guide.

Die Wahl der richtigen Methode für Ihren Anwendungsfall

Die Entscheidung zwischen Multicast und Unicast in AES67 sollte auf einer praktischen Bewertung Ihrer Umgebung basieren.

  1. Wie viele Empfänger benötigen das gleiche Audio? Wenn mehr als 3-5 Geräte identischen Inhalt benötigen, ist Multicast effizienter, während Unicast für 1-2 Empfänger einfacher sein kann.
  2. Ist die Netzwerkinfrastruktur Multicast-ready? Wenn Sie Switches mit IGMP-Snooping und PIM-Unterstützung verwaltet haben, ist Multicast praktikabel.
  3. Benötigen Sie eine Per-Stream-Customization? Unicast erlaubt unterschiedliche Sampleraten oder Kanalzahlen pro Empfänger. Multicast zwingt alle Zuhörer, das gleiche Format zu akzeptieren.
  4. Was sind Ihre Sicherheitsanforderungen? Wenn der Audiostream nicht von nicht autorisierten Geräten zugänglich sein darf (z. B. in einem Vorstandssaal oder einer Regierungseinrichtung), bietet Unicast eine bessere Isolation.
  5. Ist Synchronisation über mehrere Streams hinweg kritisch? Multicast synchronisiert alle Empfänger auf eine RTP-Uhr. Mit Unicast stellen Sie sicher, dass alle Streams denselben PTP-Großmeister verweisen, um Drift zu vermeiden.
  6. Was ist Ihre Toleranz für die Netzwerkkonfiguration Overhead? Multicast erfordert eine sorgfältige VLAN- und Routing-Einrichtung sowie die Überwachung der IGMP-Gruppenmitgliedschaft. Unicast ist eher "Plug-and-Play", kann aber die Quelle belasten.

In vielen großen Installationen funktioniert ein hybrider Ansatz am besten: Verwenden Sie Multicast für das Hauptverteilungs-Backbone (z. B. Programm-Feeds für alle Studios) und Unicast für spezifische Punkt-zu-Punkt-Anforderungen (z. B. den persönlichen Monitor des Ingenieurs). AES67-Geräte unterstützen in der Regel beide, so dass Sie sie problemlos kombinieren können.

Best Practices für die Umsetzung

Um das Beste aus dem AES67-Streaming herauszuholen, befolgen Sie diese Richtlinien:

  • Verwenden Sie eine feste Paketisierungszeit: Halten Sie sich an 1 ms oder 4 ms, wie im AES67-Profil definiert, was die Kompatibilität zwischen den Geräten und eine geringe Latenz gewährleistet.
  • PTP-Grenzuhren: Stellen Sie PTP-Grenzuhren an Schaltgrenzen bereit, um die Genauigkeit in großen Netzwerken zu gewährleisten. Vermeiden Sie transparente Uhren, wenn möglich, da sie Asymmetrien verursachen können.
  • Netzstatistiken überwachen: Verwenden Sie Tools wie Wireshark mit RTP-Analyse oder Geräte-Dashboards, um nach Paketverlust, Jitter und Timing-Fehlern zu suchen.
  • Redundanz: Für kritische Anwendungen redundante Multicast-Streams (z. B. zwei verschiedene Multicast-Gruppen) oder redundante Unicast-Pfade implementieren.
  • Etikettenströme deutlich: Verwenden Sie SAP-basierte Ankündigungen oder ein zentrales Steuerungssystem, um Streamnamen und Parameter zu bewerben, was die Erkennung vereinfacht und Konfigurationsfehler reduziert.

Für praktische Konfigurationsbeispiele, die RAVENNA Netzwerktechnologieseite bietet detaillierte Einblicke in AES67-konforme Setups.

Die Zukunft von AES67 und AoIP

AES67 entwickelt sich weiter und seine Rolle in der Interoperabilität wurde durch neuere Standards wie SMPTE ST 2110 (für Broadcast-Video und Audio) und das aufkommende AES67-2023-Update verstärkt. Das AoIP-Ökosystem umfasst jetzt Systeme mit hoher Kanalzahl, immersive Audioformate (z. B. Dolby Atmos) und cloudbasierte Produktionsworkflows. In diesen fortschrittlichen Szenarien kann sich die Wahl zwischen Multicast und Unicast verschieben: Cloud-Umgebungen verlassen sich aufgrund virtueller Netzwerkbeschränkungen oft auf Unicast, während lokale Produktionsanlagen Multicast für ihr deterministisches Verhalten bevorzugen. AES67 bleibt der Klebstoff, der sicherstellt, dass Geräte verschiedener Anbieter Audio austauschen können ohne proprietäre Lock-in. Zu verstehen, wann jede Transportmethode verwendet werden soll, ist eine grundlegende Fähigkeit für jeden, der moderne Audionetzwerke baut.

Schlussfolgerung

AES67 bietet ein robustes Framework für Audio über IP, das sowohl Multicast- als auch Unicast-Streaming ermöglicht, um eine breite Palette professioneller Anwendungsfälle zu erfüllen. Multicast zeichnet sich durch Skalierbarkeit und Bandbreiteneffizienz aus und ist damit die Standardwahl für die großflächige Verteilung von synchronisiertem Audio. Unicast bietet Flexibilität, Sicherheit und Anpassung per Stream, ideal für Punkt-zu-Punkt-Anwendungen und kleinere Bereitstellungen. Durch sorgfältige Bewertung der Anzahl der Empfänger, der Netzwerkinfrastruktur, der Synchronisierungsanforderungen und der Sicherheitsanforderungen können Sie die optimale Streaming-Methode auswählen - oder beide kombinieren - um ein zuverlässiges, leistungsstarkes Audionetzwerk aufzubauen. Da die AoIP-Landschaft weiter reift, wird die Beherrschung dieser Grundlagen sicherstellen, dass Ihr System anpassungsfähig und zukunftssicher bleibt.