Einleitung: Warum das Audioprotokoll in der modernen Rundfunk wichtig ist

In der heutigen Sendeeinrichtung ist Audio kein einfaches analoges Signal mehr, das durch dedizierte Kupferleitungen fließt. Es ist ein digitaler Stream, der Standard-Ethernet-Netzwerke durchquert, und das Protokoll, das seinen Transport regelt, ist so grundlegend wie die Akustik Ihres Kontrollraums. Das falsche Protokoll kann eine inakzeptable Latenzzeit einführen, Taktungskonflikte verursachen, Sie an einen einzigen Anbieter binden oder eine vollständige Netzwerküberholung erfordern, wenn Sie skalieren müssen. Das richtige Protokoll hingegen bietet makellose Qualität, Sub-Millisekunden-Timing und die Flexibilität, mit Video-, Gegensprech- und Produktionstools über eine einheitliche IP-Infrastruktur zu integrieren.

Diese Entscheidung ist nicht nur technisch, sondern strategisch. Ob Sie eine Green-Field-Station bauen, eine bestehende Anlage nachrüsten oder eine schrittweise Migration von einem alten MADI- oder Analogsystem planen, Ihre Protokollauswahl beeinflusst jede Ausrüstung, die Sie kaufen, jeden Netzwerkswitch, den Sie konfigurieren, und jeden Ingenieur, den Sie trainieren. Rundfunkanstalten stehen heute vor einem zunehmenden Druck, die Fernproduktion, Hybrid-Workflows und UHD-Video über IP zu unterstützen. Das Audioprotokoll, das Sie auswählen, muss mit diesen umfassenderen operativen Zielen übereinstimmen. Dieser Artikel bietet eine praktische, ausführliche Anleitung zu den Schlüsselfaktoren, den führenden Protokollen und dem Entscheidungsrahmen, der Ihnen hilft, klug zu wählen.

Audio-over-IP (AoIP) Protokolle verstehen

Audioprotokolle sind standardisierte Methoden zum Kodieren, Paketieren und Transportieren von digitalem Audio über Internet Protocol (IP)-Netzwerke. Sie definieren, wie Audio-Samples formatiert werden, wie Timing beibehalten wird (Clocking), wie Geräte sich gegenseitig entdecken und wie Streams geroutet werden. Im Gegensatz zu herkömmlichen Punkt-zu-Punkt-Verbindungen ermöglicht AoIP jedem Gerät im Netzwerk den Zugriff auf jeden Audiostream, was die Verkabelung, das Patchen und die Rekonfiguration drastisch vereinfacht.

Rundfunkeinrichtungen haben einzigartige Anforderungen: deterministische niedrige Latenz, hohe Zuverlässigkeit, Unterstützung für große Kanalzahlen und Interoperabilität mit Produktions- und Übertragungssystemen. AES67, Ravenna, Dante, und LivewireJedes dieser Systeme basiert auf ähnlichen Prinzipien (RTP, PTP), unterscheidet sich jedoch in der Implementierung, dem Ökosystem und den Funktionen. Das Verständnis dieser Unterschiede ist von entscheidender Bedeutung, da Ihre Einrichtung möglicherweise mehrere Protokolle gleichzeitig während einer Migration oder in einer Umgebung mit mehreren Anbietern unterstützen muss.

Neben den Kernprotokollen begegnen auch viele Einrichtungen MADI (Multichannel Audio Digital Interface) in Legacy-Installationen. Während MADI ein seriell-punktgenerielles Format anstelle eines IP-basierten Protokolls ist, ist es nach wie vor üblich, ältere Konsolen, Router und Aufnahmegeräte anzuschließen. Die Planung eines Konvertierungspfads von MADI zu einem nativen AoIP-Protokoll ist bei Upgrades von Einrichtungen eine häufige Überlegung.

AES67: Der Universal Interoperability Standard

AES67 ist ein offener Standard, der von der Audio Engineering Society (AES) veröffentlicht wurde; es handelt sich nicht um einen vollständigen Protokollstapel, sondern um eine Reihe von Spezifikationen, die die Interoperabilität zwischen verschiedenen AoIP-Systemen gewährleisten; es definiert die obligatorische Unterstützung für PCM-Audio, spezifische Abtastraten (48 kHz, 96 kHz) und die Verwendung des Precision Time Protocol (PTPv2) zur Synchronisation. Jedes Gerät, das AES67-konform behauptet, kann Audio mit einem anderen AES67-kompatiblen Gerät senden und empfangen, unabhängig vom zugrunde liegenden Herstellerprotokoll.

Für Anlagen, die bereits eine Mischung aus Dante-, Ravenna- oder Livewire-Ausrüstung haben, fungiert AES67 als Brücke. Es ist auch die Grundlage für SMPTE ST 2110-30, den Standard für professionelle Broadcast-Medien über IP. AES67 allein bietet jedoch keine Discovery-, Verbindungsmanagement- oder Multicast-Routing-Konfiguration - diese werden vom nativen Protokoll jedes Geräts gehandhabt. Das bedeutet, dass AES67 zwar grundlegende Transportkompatibilität garantiert, die Benutzererfahrung jedoch oft zusätzliche Software oder manuelle Konfiguration erfordert. In der Praxis müssen Sie möglicherweise Multicast-Adressen manuell für jeden Stream einrichten oder einen Routing-Manager eines Drittanbieters verwenden, um protokollübergreifende Verbindungen zu handhaben.

Der AES67-Standard hat sich weiterentwickelt. AES67-2022 Revision Einführung von 96 kHz-Proberaten, verbesserten PTP-Profilen für eine bessere Stabilität in Weitverkehrsnetzen und klareren Redundanzanforderungen. Dies macht AES67 zunehmend als primäres Protokoll für größere Einrichtungen und nicht nur als Brückenwerkzeug tragfähig. Für eine Einrichtung, die auf langfristige Flexibilität und Herstellerunabhängigkeit setzt, ist die Entwicklung auf AES67 als gemeinsame Transportschicht eine gute Strategie.

Hauptstärken: Offener Standard, herstellerneutral, zukunftssicher für Broadcast-IP-Ökosysteme, keine Lizenzgebühren pro Port. Überlegungen: Keine eingebaute Geräteerkennung; erfordert eine sorgfältige Netzwerkplanung für PTP und Multicast; erfordert möglicherweise zusätzliche Verwaltungssoftware.

Erfahren Sie mehr über die AES-Normenseite.

Dante: Der Führer der Benutzerfreundlichkeit

Dante, entwickelt von Audinate, ist das am weitesten verbreitete AoIP-Protokoll in der Welt der Audio- und Broadcast-Dienste. Sein Hauptvorteil ist die Einfachheit: Dante-fähige Geräte entdecken sich automatisch im Netzwerk und Audio-Routing wird über eine freie Software-Anwendung (Dante Controller) verwaltet. Latenz ist von 0,25 ms bis 10 ms konfigurierbar, wodurch es für Live-Mikrofon-Feeds und Studiomonitore gleichermaßen geeignet ist. Die automatischen Erkennungs- und Routing-Funktionen reduzieren den Zeitaufwand für die Einrichtung eines neuen Systems erheblich, weshalb Dante in schnelllebigen Produktionsumgebungen beliebt ist.

Dante unterstützt bis zu 1024 x 1024 Audiokanäle pro Gerät mit redundanten Netzwerkpfaden (Dante Redundant), und seine Taktung ist sehr robust. Das Ökosystem ist enorm, da Hunderte von Herstellern Dante-Karten und integrierte Schnittstellen anbieten. Für Sendeeinrichtungen wird Dante oft gewählt, wenn die Hauptanforderung eine schnelle Bereitstellung und eine große bestehende Produktbasis ist. Es gibt jedoch Nuancen: Das Standard-Dante-System verwendet ein einziges Subnetz und leitet Audio nicht nativ über VLANs ohne den Zusatz von Dante Domain Manager, der Kosten pro Abonnement einführt.

Für Einrichtungen, die mit Video-over-IP-Workflows integriert sind, bietet Dante die Dante AVIO Die Adapterlinie und die Unterstützung für die AES67-Brückenführung auf vielen neueren Geräten. Audinate nimmt auch am SMPTE ST 2110-Ökosystem teil, obwohl sich das native Protokoll von Dante vom AES67/RTP-Modell unterscheidet, das in ST 2110 verwendet wird.

Hauptstärken: Benutzerfreundlichkeit, automatische Erkennung, breites Produktökosystem, geringe Latenz, robustes Takten. Überlegungen: Proprietäre Lizenzierung erhöht die Kosten pro Gerät (normalerweise $ 50- $ 150 pro Endpunkt); nicht nativ kompatibel mit SMPTE ST 2110 ohne zusätzliche Überbrückung; Einschränkungen im Einzel-Subnetz ohne Domain Manager.

Ravenna: Hochleistung für große Installationen

Ravenna ist eine offene Technologie, die ursprünglich von ALC Network (heute Teil der AES67-Ravenna-Allianz) entwickelt wurde. Sie betont hohe Kanaldichte, Latenzzeiten unter Millisekunden und Redundanz. Ravenna verwendet Standard IEEE 1588 PTPv2 für Synchronisation und RTP für Transport und ist standardmäßig vollständig AES67-kompatibel. Sie wird in Broadcast-Konsolen, Routing-Matrizen und Intercom-Systemen von Herstellern wie Lawo, DirectOut, Neumann und Merging Technologies weit verbreitet. Ravennas Architektur ist von Grund auf für groß angelegte Installationen konzipiert, was sie zu einer beliebten Wahl für große Broadcast-Zentren und OB (Outside Broadcast) -LKWs macht.

Die Stärke von Ravenna liegt in der Fähigkeit, große Installationen mit Hunderten von gleichzeitigen Streams zu handhaben, während das Timing deterministisch bleibt. Es unterstützt sowohl Unicast als auch Multicast und bietet erweiterte Netzwerkredundanzfunktionen wie nahtlose Umschaltung mit RSTP oder proprietärer Link-Aggregation. Das Protokoll unterstützt auch eine breite Palette von Sampleraten (bis zu 192 kHz) und Bittiefen, wodurch es für hochauflösende Audioanwendungen über die Standardübertragung hinaus geeignet ist. Für Einrichtungen, die eine Integration in SMPTE ST 2110 Video planen oder eine Zukunftssicherheit für die 4K/8K-Produktion erfordern, ist Ravenna ein starker Kandidat, weil es die gleichen zugrunde liegenden Transportstandards (RTP, PTP) teilt wie ST 2110.

Eine praktische Überlegung ist, dass Ravenna-Bereitstellungen typischerweise mehr Netzwerk-Know-how erfordern als Dante. Ravenna Web Manager Die erste Einrichtung – insbesondere für Multicast-Routing und PTP-Hierarchie – erfordert eine sorgfältige Planung. Einmal konfiguriert, sind Ravenna-Systeme jedoch extrem stabil und skalierbar. Viele Anlagen, die Ravenna betreiben, berichten von jahrelangem störungsfreiem Betrieb ohne Taktverschiebung und minimalem Jitter.

Hauptstärken: Hohe Kanalzahlen, ausgezeichnete Taktung, offener Standard (königlich frei), starke Unterstützung des Broadcast-Anbieters, native ST 2110-Ausrichtung. Überlegungen: Etwas steilere Lernkurve als Dante; Discovery- und Verbindungsmanagement sind manueller; erfordert qualitativ hochwertige Managed Switches mit PTP-Unterstützung.

Livewire: Streamlined für Rundfunk und Radio

Livewire, entwickelt von Telos Alliance, war eines der ersten AoIP-Systeme, das speziell für Rundfunk-Radio entwickelt wurde. Es verwendet das Livewire+ Protokoll, das auf der gleichen RTP/PTP-Basis wie AES67 aufgebaut ist. Livewire ist bekannt für seine enge Integration mit Telos Telefonsystemen, Axia Konsolen und anderen Broadcast-Peripheriegeräten. Es bietet eine automatische Konfiguration, integrierte GPIO über IP und eine einfache Namenskonvention für Audiokanäle, die mit der Broadcast-Workflow-Terminologie übereinstimmt (z. B. "Studio 1 Mic 1").

Livewire ist besonders beliebt bei Radiosendern und kleineren TV-Einrichtungen, wo das Ökosystem von Telos/Axia-Geräten bereits im Einsatz ist. Die neuesten Livewire+-Implementierungen sind AES67-kompatibel, so dass sie mit anderen Protokollen im Netzwerk kommunizieren können. Das bedeutet, dass eine Livewire-basierte Einrichtung Dante-Geräte bei Bedarf über AES67 integrieren kann, obwohl die Konfiguration manuelle Schritte erfordern kann. Eine Besonderheit von Livewire ist die Unterstützung von "Logic" über IP-GPIO und Steuersignale, die neben Audiostreams übertragen werden, was Automatisierung und Tally-Systeme vereinfacht.

Allerdings ist das Geräte-Ökosystem außerhalb der Telos-Welt begrenzter als Dante oder Ravenna. Wenn Sie sich für Livewire entscheiden, verpflichten Sie sich strategisch zum Telos Alliance-Ökosystem für Konsolen, Telefonsysteme und Peripheriegeräte. Dies kann ein Vorteil sein, wenn Sie bereits Telos-Ausrüstung verwenden, aber es schränkt die Flexibilität ein, wenn Sie später Geräte von Drittanbietern integrieren möchten, denen Livewire-native Unterstützung fehlt. Livewire eignet sich am besten für Einrichtungen, in denen die Integration und Einfachheit von Broadcast-Workflows oberste Priorität haben und wo die gesamte Audiokette um Telos-Produkte standardisiert werden kann.

Hauptstärken: Einfache Einrichtung, integrierte Broadcast-Workflow-Tools, integrierte GPIO über IP, AES67-Compliance in den neuesten Versionen. Überlegungen: Am besten geeignet, wenn man sich für Telos/Axia-Ausrüstung einsetzt; weniger Anbietervielfalt; kleineres Ökosystem für Geräte von Drittanbietern.

Kritische Entscheidungsfaktoren

Neben den Protokollfunktionen muss Ihre Wahl mit der Betriebsrealität Ihrer Einrichtung übereinstimmen.

Kompatibilität und Interoperabilität

Keine Einrichtung ist eine Insel. Sie müssen Audio mit Produktionsstudios, Remote-Trucks, Streaming-Encodern und Übertragungsanlagen austauschen. Wenn Ihr gewähltes Protokoll nicht AES67-fähig ist, können Sie mit kostspieligen Gateways oder Formatkonvertern konfrontiert sein. Suchen Sie nach Geräten, die AES67 oder SMPTE ST 2110-30 nativ unterstützen. Betrachten Sie auch die zukünftige Integration mit Video-over-IP (SMPTE ST 2110), die normalerweise AES67 für die Audioessenz erfordert.

Wenn Sie beispielsweise eine Verbindung zu einem zentralen Router planen, der sowohl Video als auch Audio verarbeitet, ist es unerlässlich, dass Ihr Audioprotokoll die gleiche PTP-Domäne wie Ihre Videoinfrastruktur verwendet, um Fehlanpassungen zu vermeiden.

In Multiprotokollumgebungen: Planen Sie eine Gateway-Strategie. Einige Hersteller bieten Hardware-Brücken (z. B. die CONVERTER-Serie von DirectOut) an, die in Echtzeit zwischen Dante, Ravenna, MADI und AES67 übersetzen. Softwarebasierte Lösungen existieren ebenfalls, aber sie können Latenzzeiten oder Verarbeitungsaufwand einführen. Der Schlüssel ist, nicht nur zu bewerten, ob zwei Protokolle nebeneinander existieren können, sondern auch, wie sauber und zuverlässig sie unter Broadcast-Lasten interagieren.

Latenzanforderungen

Für Live-Übertragungen ist häufig eine Latenzzeit unter 1 Millisekunde für die Foldback-, Gegensprech- und Mikrofonüberwachung erforderlich. Dante und Ravenna können 125 Mikrosekunden bei den niedrigsten Puffereinstellungen erreichen, während AES67-Implementierungen typischerweise mit 1 ms oder höher laufen. Testen Sie die tatsächliche Latenz mit Ihrer Netzwerkhardware. Berücksichtigen Sie auch die kumulative Latenz über mehrere Hops: Wenn Sie Einrichtungen über ein WAN verbinden, müssen Sie möglicherweise Netzwerkausbreitungsverzögerungen berücksichtigen. In einer verteilten Einrichtung mit mehreren Gebäuden könnte die Gesamt-End-zu-End-Latenz sogar mit Protokollen mit niedriger Latenz auf 3-5 ms steigen.

Einige Protokolle erlauben es, Latenz gegen Netzwerkrobustheit zu tauschen. Ein kleinerer Puffer reduziert Latenz, erhöht aber das Risiko von Ausfällen durch Netzwerkjitter. In einem gut konzipierten Netzwerk mit verwalteten Switches und dedizierter QoS können Sie sicher mit den niedrigsten Puffereinstellungen arbeiten. Wenn Ihre Netzwerkinfrastruktur weniger kontrolliert ist oder drahtlose Verbindungen enthält, ist eine etwas höhere Puffereinstellung (z. B. 2 ms) möglicherweise sicherer. Planen Sie, Ihr Latenzbudget mit einem Testsignal und einem Oszilloskop oder Phasenmesser zu validieren, bevor Sie das System in Betrieb nehmen.

Netzwerkinfrastruktur und Bandbreite

Broadcast AoIP verwendet normalerweise Multicast für eine effiziente Verteilung. Dies erfordert IGMP-Snooping, das auf Ihren verwalteten Ethernet-Switches aktiviert ist, sowie eine robuste PTP-Grenzuhr oder eine gewöhnliche Takthierarchie. Unverwaltete Switches sind nicht geeignet. Die Bandbreite ist selten ein Problem: Ein einzelner unkomprimierter 48 kHz/24-Bit-Stereokanal benötigt etwa 2,3 Mbit / s. Selbst ein 128-Kanal-System ist weit unter 1 Gbit / s. Allerdings müssen Sie planen, dass redundante Netzwerke (primär und sekundär) einen Switchausfall überleben, ohne Audio zu verlieren. Das bedeutet, dass Sie Ihre Switch-Infrastruktur und Verkabelung verdoppeln müssen, was in großen Einrichtungen erhebliche Kosten verursachen kann.

Netzwerk-Switches für AoIP sollten über hochwertige Taktoszillatoren verfügen, um die Funktionalität von PTP transparenten Uhren oder Boundary Clocks zu unterstützen. Nicht alle verwalteten Switches sind in dieser Hinsicht gleich. Switches von Herstellern wie Cisco, Arista, Netgear und Luminex bieten spezifische Modelle, die für die AoIP-Nutzung zertifiziert sind. Überprüfen Sie die vom Hersteller empfohlene Switch-Liste für das von Ihnen gewählte Protokoll. Planen Sie auch eine Link-Aggregation, wenn Sie mehr als 1 Gbps Durchsatz benötigen - obwohl dies selten für Audio allein notwendig ist, kann es erforderlich sein, wenn Sie Audio mit Video kombinieren, Steuerung und Dateiverkehr im selben Netzwerk.

Skalierbarkeit und zukünftiges Wachstum

Wählen Sie ein Protokoll, das sowohl in der Kanalanzahl als auch in der geografischen Reichweite skaliert. Ravenna- und AES67-basierte Systeme können leicht auf Tausende von Kanälen über mehrere Gebäude mit einer ordnungsgemäßen PTP-Verteilung wachsen. Dante skaliert auf 1024 Kanäle pro Gerät, kann aber durch das Single-Domain-Konzept eingeschränkt werden; Dante Domain Manager ermöglicht die Skalierung über VLANs und Standorte hinweg, erhöht jedoch die Kosten. Livewire eignet sich besser für eine einzelne Einrichtung oder einen Campus mit einer moderaten Größe. Untersuchen Sie bei Einrichtungen mit mehreren Gebäuden oder Remote-Studios, ob das Protokoll einen Wide-Area-Betrieb über IP-Verbindungen mit akzeptabler Latenz und Zuverlässigkeit unterstützt.

Ein Protokoll, das in Ihrer Region oder von Ihren Mitarbeitern häufig verwendet wird, ist möglicherweise einfacher zu pflegen und zu beheben als ein weniger häufiges. Faktor in der Verfügbarkeit von Schulungen, Zertifizierungsprogrammen und Unterstützung durch Dritte. Zum Beispiel bietet Dante Zertifizierungsstufen von Associate to Expert an, die für die Personalentwicklung nützlich sein können.

Kosten des Eigentums

Lizenzgebühren werden in die Hardwarekosten eingebrannt. Dante hat eine Lizenzgebühr pro Port, die oft 50 bis 150 US-Dollar pro Endpunkt hinzufügt. Ravenna und AES67 sind gebührenfrei, so dass ihre Hardware billiger sein kann, aber Sie zahlen für fortschrittliche Netzwerk-Switches und möglicherweise für Software-Management-Tools. Faktor bei den Schulungskosten: Ingenieure, die mit einem Protokoll vertraut sind, brauchen möglicherweise Zeit, um ein anderes zu lernen. Die Gesamtbetriebskosten umfassen einen Ersatzteilbestand, Netzwerkwartung und jede Überbrückungshardware, die für die Interoperabilität mit Legacy-Systemen benötigt wird.

In einer großen Anlage mit Hunderten von Audio-Endpunkten können sich die Lizenzkosten pro Port von Dante erheblich summieren, was möglicherweise Ravenna- oder AES67-native Lösungen kosteneffektiver im Maßstab macht.

Wenn Ihre Einrichtung die Konformität mit SMPTE ST 2110 verlangt, müssen Sie möglicherweise für formelle Konformitätstests auf Ihren Geräten und Ihrem Netzwerk bezahlen. Dies ist häufiger in großen Sendezentren und Netzwerkbetriebsknotenpunkten.

Praktische Überlegungen zum Netzwerkdesign

Die Implementierung von AoIP in einer Broadcast-Einrichtung ist keine Plug-and-Play-Übung. Sie müssen Ihr Netzwerk so gestalten, dass es die spezifischen Anforderungen des von Ihnen gewählten Protokolls unterstützt.

Precision Time Protocol (PTP) und Clocking

Alle AoIP-Protokolle setzen auf PTPv2 (IEEE 1588-2008), um Sample-Uhren über alle Geräte hinweg zu synchronisieren. Eine PTP-Grandmaster-Uhr (oftmals extern GPS-diszipliniert) bietet eine Master-Zeitreferenz. Für Einrichtungen mit Video müssen Sie möglicherweise Audio-PTP an die Videoreferenz sperren (wie z. B. genlock), um ein Driften während der Produktion zu vermeiden. Stellen Sie sicher, dass Ihre Netzwerk-Switches PTP-fähig sind (transparente Uhren oder Boundary-Uhren), um die Genauigkeit unter Mikrosekunden über viele Hops hinweg zu gewährleisten. In einer großen Einrichtung mit mehreren Switch-Ebenen planen Sie Ihre PTP-Hierarchie sorgfältig: Jeder Switch sollte möglichst als Boundary-Uhr konfiguriert werden, anstatt sich auf den End-to-End-Transparent-Clock-Modus zu verlassen, der über viele Hops ungenau wird.

Einige Einrichtungen wählen separate PTP-Domänen für Audio und Video, um Zeitprobleme zu isolieren. Dies erhöht jedoch die Komplexität und erfordert ein sorgfältiges Management an den Grenzen. Ein einfacherer Ansatz ist die Verwendung einer einzigen Grandmaster-Uhr mit einem PTP-Profil, das sowohl Audio (IEEE 1588-Profil für AES67) als auch Video (SMPTE ST 2059-2) unterstützt. Viele moderne Grandmaster-Uhren können mehrere Profile gleichzeitig ausgeben. Testen Sie Ihre Uhrenrückgewinnungskette gründlich, bevor Sie sie in Produktion bringen.

Servicequalität (QoS)

Audiopakete müssen über Datenverkehr priorisiert werden, um Jitter und Paketverlust zu vermeiden. DSCP-Markierung auf Switches konfigurieren: typischerweise DSCP 46 (Expedited Forwarding) für Audiostreams. Setzen Sie Warteschlangen mit strenger Priorität und begrenzen Sie die Bandbreitennutzung, um Staus zu vermeiden. Testen Sie Ihr Netzwerk mit einem Paketgenerator, bevor Sie echte Audiogeräte anschließen. In einem konvergierten Netzwerk, das Audio, Video und Daten enthält, benötigen Sie möglicherweise mehrere Verkehrsklassen: Voice/Audio (höchste Priorität), Streaming-Video (medium), Steuerdaten (medium-low) und Best-Effort-Daten (lowest).

Definieren und erzwingen Sie diese Warteschlangenrichtlinien für alle Switches.

Berücksichtigen Sie auch die Auswirkungen der Multicast-MAC-Adressfilterung. Jeder Audiostream verwendet eine Multicast-MAC-Adresse, und Switches müssen diese effizient lernen und weiterleiten. IGMP-Schnüffeln aktivieren und einen Abfrager für jedes VLAN konfigurieren, das Multicast-Audio mit sich führt. Ohne eine ordnungsgemäße IGMP-Konfiguration können Switches den Multicast-Datenverkehr zu allen Ports überschwemmen, Bandbreite verschwenden und Paketverlust verursachen.

Redundanz und Failover

Sendezeit kann sich keine Ausfallzeiten leisten. Implementieren eines parallelen sekundären Netzwerks (separate Switches und Kabel) für das primäre Audioprotokoll. Der Redundant-Modus von Dante und der nahtlose Schutzschalter von Ravenna erfordern beide zwei unabhängige Netzwerkpfade. Planen Sie eine automatische Umschaltung in weniger als einem Audioframe (normalerweise) < 4 ms). Document your network topology and test failover scenarios regularly. In practice, many facilities run primary and secondary networks in an active/standby configuration, with the secondary network fully isolated and tested weekly. Some advanced setups use link aggregation or even LAG with active/active traffic, but this requires careful validation of switch convergence times.

Die meisten von ihnen sind nicht nur ein paar, sondern auch ein paar, aber auch ein paar, die meisten von ihnen sind nicht nur ein paar, sondern auch ein paar, die meisten von ihnen sind nicht nur ein paar, sondern auch ein paar.

Zukunftssicher mit SMPTE ST 2110 und AES67

Der Trend in der Übertragung geht in Richtung einer vollständigen IP-basierten Produktion, bei der Video, Audio und Daten alle im selben Netzwerk mit SMPTE ST 2110-Standards übertragen werden. Audio in ST 2110 wird durch ST 2110-30 (PCM-Audio, im Wesentlichen AES67) und ST 2110-31 (AES3-Transport) definiert. Wenn Sie in den nächsten Jahren auf IP-Video umsteigen wollen, wird die Auswahl eines Audioprotokolls, das nativer ST 2110-30-kompatibel ist, eine größere Umarchitektur vermeiden. Sowohl Ravenna als auch Dante (mit Dante AVIO oder Dante Domain Manager) können integriert werden, aber Ravenna ist direkter auf ST 2110 ausgerichtet, da es die gleichen zugrunde liegenden Standards und PTP-Profile verwendet.

Für reine Funkanlagen mag ST 2110 weniger relevant sein, aber AES67 bleibt das Rückgrat der Interoperabilität. Die AES67-2022-Revision hat die Unterstützung für 96 kHz und verbesserte PTP-Profile hinzugefügt, wodurch es noch robuster wird. Selbst wenn Sie heute nicht auf Video-over-IP umsteigen, behält die Wahl eines AES67-fähigen Protokolls Ihre Optionen für die zukünftige Zusammenarbeit mit Videoproduktionsteams, Remote-Trucks und Cloud-basierten Workflows. Die Broadcast-Branche konvergiert ständig auf IP-Standards, und eine Einrichtung, die heute in AES67-Compliance investiert, wird morgen weniger Kompatibilitätshürden haben.

Ein weiterer aufkommender Trend ist die cloudbasierte Audioverarbeitung. Mehrere Anbieter bieten jetzt virtualisierte Audiorouter und Verarbeitungsmaschinen an, die auf Standard-Server-Hardware laufen und sich über AoIP mit der Einrichtung verbinden. Diese Systeme verlassen sich normalerweise auf AES67 oder ST 2110-30, um mit physischer Ausrüstung zu interagieren. Wenn Sie erwarten, dass einige Verarbeitungen (Mischen, Routing, Kodierung) in die Cloud verschoben werden, stellen Sie sicher, dass das von Ihnen gewählte Audioprotokoll eine Brücke zu einer Cloud-Umgebung mit geringer Latenz und Unterstützung für das Netzwerk-Timing über das WAN schlagen kann.

Fallstudie: Auswahl eines Protokolls für eine mittelgroße TV-Nachrichteneinrichtung

Betrachten wir eine Einrichtung mit 6 Kontrollräumen, 4 Studios und einem zentralen Maschinenraum. Sie planen, einen alten analogen Router durch AoIP zu ersetzen. Die Einrichtung verfügt bereits über eine Konsole eines Ravenna-unterstützenden Herstellers (Lawo), verwendet aber auch drahtlose Mikrofonempfänger mit Dante-Ausgängen. Nach der Analyse wählt das Ingenieurteam Ravenna als Rückgrat, weil es AES67-konform ist und es den Dante-Geräten ermöglicht, sich über AES67-Bridgeing zu verbinden. Sie installieren eine PTP-Großmeisteruhr und verwalten das Multicast-Routing über einen zentralen Software-Controller.

Das Ergebnis ist eine einzige IP-Infrastruktur für alle Audiogeräte, mit Platz für 2110 Videos in der Zukunft.

Die wichtigste Lehre aus dieser Fallstudie ist die Wahl eines Protokolls, das Ihre bestehenden Inseln verbindet, anstatt ein Ökosystem mit einem einzigen Anbieter zu erzwingen. Das Team investierte in ein Gateway (DirectOut EXBOX.MD), um Dante-Streams für das Ravenna-Netzwerk in AES67 umzuwandeln. Dies fügte einige Kosten und Komplexität hinzu, bewahrte jedoch die bestehende Investition in drahtlose Mikrofone. Mit der Zeit, wenn Dante-Geräte ersetzt werden, kann das Team auf Ravenna-native Ausrüstung umsteigen, was die Architektur weiter vereinfacht. Die Einrichtung implementierte auch ein separates Management-VLAN für den gesamten AoIP-Kontrollverkehr, um sicherzustellen, dass Routing-Befehle und Statusaktualisierungen die Audioströme nicht beeinträchtigen.

Schritt-für-Schritt-Entscheidungsrahmen

  1. Auditieren Sie Ihre vorhandenen Geräte. Liste jedes Audiogerät, seine aktuelle Protokollunterstützung und seine erwartete Lebensdauer, einschließlich Konsolen, Mikrofonempfänger, Gegensprechanlagen, Routingmatrizen und Aufzeichnungsgeräte, notieren Sie, welche Geräte über eine integrierte AES67-Fähigkeit verfügen und welche Adapter erfordern.
  2. Definieren Sie Ihre Latenz- und Kanalanzahlanforderungen. Für eine Live-Talkshow ist Latenz unter 1 ms entscheidend. Für die Radiowiedergabe können 2-5 ms akzeptabel sein. Zählen Sie Ihre aktuellen und zukünftigen Kanalanforderungen, wobei das Wachstum für neue Studios oder Produktionen berücksichtigt wird.
  3. Bestimmen Sie Ihre Video-Integrations-Roadmap. Wenn Sie planen, zu IP-Videos zu wechseln, priorisieren Sie die AES67/ST 2110-Kompatibilität.Wenn Sie die SDI für die nächsten fünf Jahre beibehalten, ist die Protokollauswahl weniger eingeschränkt, aber Sie sollten dennoch die Interoperabilität mit Remote-Produktionspartnern berücksichtigen, die IP verwenden können.
  4. Bewerten Sie Ihre Netzwerkbereitschaft. Können Ihre Switches PTP, IGMP und QoS verarbeiten? Haben Sie ein Budget für ein redundantes Netzwerk? Wenn Ihre Netzwerkinfrastruktur altert, berücksichtigen Sie die Kosten für das Upgrade auf verwaltete Switches mit PTP-Grenztaktfähigkeit.
  5. Wählen Sie zwei oder drei Kandidatenprotokolle. Testen Sie sie in einem Labor mit repräsentativer Ausrüstung, bevor Sie sie festlegen. Verwenden Sie einen Testplan, der Latenz, Jitter, Uhrenstabilität und Failover-Zeit misst. Fügen Sie mindestens ein Produktions-Audio-Szenario hinzu, das Ihren typischen Workflow widerspiegelt.
  6. Betrachten Sie Vendor Lock-in Risiken. Wenn Sie ein proprietäres Protokoll wählen, sollten Sie einen dokumentierten Migrationspfad zu AES67 oder ST 2110 haben, falls später erforderlich.
  7. Plan für Ausbildung und Unterstützung. Stellen Sie sicher, dass Ihr Engineering-Team das gewählte System pflegen kann. Budget für Herstellerschulungen, Zertifizierungsprogramme und externe Berater, wenn internes Fachwissen fehlt. Dokumentieren Sie Ihre Netzwerkdesign- und Workflow-Verfahren gründlich.

Schlussfolgerung

Die Wahl des richtigen Audioprotokolls für Ihre Sendeeinrichtung ist eine mehrdimensionale Entscheidung, die die technische Leistung, die vorhandene Ausrüstung, das zukünftige Wachstum und das Budget in Einklang bringt. Es gibt kein universelles "bestes" Protokoll; vielmehr ist die beste Wahl diejenige, die sich an den spezifischen Workflow und die Roadmap Ihrer Einrichtung anpasst. AES67 bietet die Grundlage für die Interoperabilität aller Systeme, während Dante Einfachheit bietet, Ravenna eine Leistung mit hoher Kanaldichte bietet und Livewire sich eng in Broadcast-Konsolen integrieren lässt. Beginnen Sie damit, Ihre Latenz- und Skalierbarkeitsanforderungen zu verstehen und dann die Ökosystem- und Netzwerkanforderungen jedes Protokolls zu bewerten. Mit sorgfältiger Planung und Tests können Sie eine Audio-over-IP-Infrastruktur aufbauen, die Ihre Einrichtung zuverlässig für die kommenden Jahre bedient.

Die Broadcast-Branche bewegt sich stetig in Richtung einer vollständigen IP-Produktion, und Audioprotokolle sind das Fundament dieses Übergangs. Indem Sie heute eine fundierte, strategische Entscheidung treffen, positionieren Sie Ihre Einrichtung, um sich an neue Workflows, neue Partner und neue Technologien ohne kostspielige Nacharbeit anzupassen. Investieren Sie in Ihr Netzwerkdesign, testen Sie gründlich und trainieren Sie Ihr Team - die Audiozukunft Ihrer Einrichtung hängt davon ab.

Für weitere Lektüre, erkunden Sie die Ravenna Ökosystem und die Audinate Dante technische RessourcenDie SMPTE ST 2110 Standardsuite ist dokumentiert bei SMPTE-WebsiteFür einen tieferen Einblick in PTP-Timing und Netzwerkdesign für die Übertragung konsultieren Sie die IEEE-Norm 802.1AS.