Benutzer:Stefdy/AES67
AES67 ist ein technischer Standard für die Interoperabilität von Audio over IP und Audio over Ethernet (AoE). Der Standard wurde von der Audio Engineering Society entwickelt und erstmals im September 2013 veröffentlicht. Es handelt sich um eine Layer-3-Protokollsuite, die auf bestehenden Standards basiert und die Interoperabilität zwischen verschiedenen IP-basierten Audio-Netzwerksystemen wie RAVENNA, Livewire, Q-LAN und Dante ermöglichen soll.
AES67 verspricht die Interoperabilität zwischen bisher konkurrierenden vernetzten Audiosystemen und die langfristige Zusammenarbeit zwischen den Systemen im Netz. Außerdem bietet es Interoperabilität mit Layer-2-Technologien wie Audio-Video-Bridging (AVB). Seit seiner Veröffentlichung wurde AES67 von mehreren Herstellern unabhängig implementiert und von vielen anderen übernommen.
Überblick
[Bearbeiten | Quelltext bearbeiten]AES67 definiert Anforderungen für die Synchronisierung von Uhren, die Festlegung von QoS-Prioritäten für den Medienverkehr und die Initiierung von Medienströmen mit Standardprotokollen aus der Internet-Protokollsuite. AES67 definiert auch das Audio-Sample-Format und die Sample-Rate, die unterstützte Anzahl von Kanälen sowie die Anforderungen an die Größe von IP-Datenpaketen und die Latenz/Pufferung.
Die Norm sieht mehrere Protokolloptionen für die Geräteerkennung vor, schreibt aber nicht vor, dass diese implementiert werden müssen. Das Session Initiation Protocol wird für die Verwaltung von Unicast-Verbindungen verwendet. Für Multicast-Verbindungen ist kein Verbindungsmanagementprotokoll definiert.
Synchronisierung
[Bearbeiten | Quelltext bearbeiten]AES67 verwendet das IEEE 1588-2008 Precision Time Protocol (PTPv2) für die Uhrensynchronisation. Für Standard-Netzwerkgeräte definiert AES67 Konfigurationsparameter für ein "PTP-Profil für Medienanwendungen", das auf IEEE 1588 Delay-Request-Response-Synchronisation und (optional) Peer-to-Peer-Synchronisation (IEEE 1588 Anhänge J.3 und J4) basiert; Ereignismeldungen werden in IPv4-Pakete über UDP-Transport (IEEE 1588 Anhang D) eingekapselt. Einige der Standardparameter wurden angepasst, insbesondere wurden logSyncInterval und logMinDelayReqInterval reduziert, um die Genauigkeit und die Startzeit zu verbessern. Clock Grade 2, wie in AES11 Digital Audio Reference Signal (DARS) definiert, wird mit clockClass signalisiert.
Netzwerkgeräte, die der Norm IEEE 1588-2008 entsprechen, verwenden Standard-PTP-Profile; für Videoströme kann das PTP-Profil SMPTE 2059-2 verwendet werden.
In AVB/TSN-Netzen wird die Synchronisation mit dem IEEE 802.1AS-Profil für zeitabhängige Anwendungen (Time-Sensetive Applications) erreicht.
Die Medieclock basiert auf einer synchronisierten Netzwerkzeit mit einer IEEE 1588-Epoche (1. Januar 1970 00:00:00 TAI). Die Taktraten sind auf Audio-Abtastfrequenzen von 44,1 kHz, 48 kHz und 96 kHz (d. h. tausend Samples pro Sekunde) festgelegt. Der RTP-Transport arbeitet mit einem festen Zeitversatz zum Netztakt.
Transport
[Bearbeiten | Quelltext bearbeiten]Die Mediendaten werden in IPv4-Paketen transportiert, wobei versucht wird, die IP-Fragmentierung zu vermeiden.
Echtzeit-Transportprotokoll mit RTP-Profil für Audio und Video (Formate L24 und L16) wird über UDP-Transport verwendet. Die RTP-Nutzlast ist auf 1460 Bytes begrenzt, um eine Fragmentierung mit der Standard-Ethernet-MTU von 1500 Bytes zu verhindern (nach Abzug des IP/UDP/RTP-Overheads von 20+8+12=40 Bytes). CSRC-Kennungen (Contributing Source) und TLS-Verschlüsselung werden nicht unterstützt.
Zeitsynchronisierung, Medienstromübertragung und Erkennungsprotokolle können IP-Multicasting mit IGMPv2 (optional IGMPv3) Aushandlung verwenden. Jedem Medienstrom wird eine eindeutige Multicast-Adresse zugewiesen (im Bereich von 239.0.0.0 bis 239.255.255.255); nur ein Gerät kann an diese Adresse senden (Many-to-Many-Verbindungen werden nicht unterstützt).
Um den Keepalive-Status zu überwachen und Bandbreite zuzuweisen, können Geräte RTCP-Berichtsintervalle, SIP-Sitzungszeitgeber und OPTIONS-Ping oder ICMP-Echo-Request (Ping) verwenden.
AES67 verwendet DiffServ, um QoS-Verkehrsprioritäten im DSCP-Feld (Differentiated Services Code Point) des IP-Pakets festzulegen. Es sollten mindestens drei Klassen unterstützt werden:
| Class name | Traffic type | standardmäßige DiffServ-Klasse (DSCP decimal value) |
|---|---|---|
| Clock | IEEE 1588-2008 time events * | EF (46) |
| Media | RTP / RTCP media streams | AF41 (34) |
| Best effort | IEEE 1588-2008 signaling, discovery and connection management | DF (0) |
- Announce, Sync, Follow_Up, Delay_Req, Delay_Resp, Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up
Für zeitkritische Anwendungen kann eine maximale Verzögerung von 250 μs erforderlich sein, um Audioausfälle zu vermeiden. Um kritische Medienströme in einem großen Netz zu priorisieren, können Anwendungen zusätzliche Werte in der Assured-Forwarding-Klasse 4 mit geringer Ausfallwahrscheinlichkeit (AF41) verwenden, die in der Regel als gewichtete Round-Robin-Warteschlange implementiert ist. Uhrenverkehr wird der Klasse Expedited Forwarding (EF) zugewiesen, die in der Regel ein strenges Prioritätsverhalten pro Hop (PHB) implementiert. Der gesamte übrige Verkehr wird nach dem Best-Effort-Prinzip mit Default Forwarding abgewickelt.
Das RTP-Taktquellensignalisierungsverfahren wird zur Angabe der PTP-Domäne und der Grandmaster-ID für jeden Medienstrom verwendet.
Audio Encodierung
[Bearbeiten | Quelltext bearbeiten]Zu den Abtastformaten gehören 16-Bit und 24-Bit Linear PCM mit einer Abtastfrequenz von 48 kHz sowie optional 24-Bit 96 kHz und 16-Bit 44,1 kHz. Andere RTP-Audio-Videoformate können unterstützt werden. Mehrere Abtastfrequenzen sind optional. Geräte können eine globale Abtastfrequenzeinstellung erzwingen.
Medienpakete werden nach der "Paketzeit" geplant - der Übertragungsdauer eines Standard-Ethernet-Pakets. Die Paketzeit wird von der Stream-Quelle für jede Streaming-Sitzung ausgehandelt. Kurze Paketzeiten sorgen für geringe Latenzzeiten und hohe Übertragungsraten, verursachen aber einen hohen Overhead und erfordern leistungsfähige Geräte und Verbindungen. Lange Paketzeiten erhöhen die Latenzzeiten und erfordern mehr Pufferung. Es ist ein Bereich von 125 μs bis 4 ms definiert, wobei empfohlen wird, dass sich die Geräte an Änderungen der Paketzeiten anpassen und/oder die Paketzeiten durch Analyse der RTP-Zeitstempel bestimmen.
Die Paketzeit bestimmt die Größe der RTP-Nutzlast in Abhängigkeit von der unterstützten Abtastrate. 1 ms ist für alle Geräte erforderlich. Die Geräte sollten mindestens 1 bis 8 Kanäle pro Stream unterstützen.
| Packet time | Samples per packet | Hinweise | |
|---|---|---|---|
| 44.1 / 48 kHz | 96 kHz | ||
| 125 μs | 6 | 12 | Compatible with AVB Class A |
| 250 μs | 12 | 24 | High-performance low-latency operation. Compatible with AVB Class B, interoperable with AVB Class A |
| 333 1⁄3 μs | 16 | 32 | Efficient low-latency operation |
| 1 ms | 48 | 96 | Required packet time for all devices |
| 4 ms | 192 | 384 | Wide area networks, networks with limited QoS capabilities, or interoperability with EBU 3326 |
- MTU-Größenbeschränkungen begrenzen einen 96-kHz-Audiostrom mit 4 ms Paketlaufzeit auf einen einzigen Kanal.
| Audio format | Packet time | ||||
|---|---|---|---|---|---|
| 125 μs | 250 μs | 333 1⁄3 μs | 1 ms | 4 ms | |
| 48 kHz / 16 bit | 120 | 60 | 45 | 15 | 3 |
| 48 kHz / 24 bit | 80 | 40 | 30 | 10 | 2 |
| 96 kHz / 24 bit | 40 | 20 | 15 | 5 | 1 |
Latenz
[Bearbeiten | Quelltext bearbeiten]Die Netzwerklatenz (Link-Offset) ist die Zeitdifferenz zwischen dem Moment, in dem ein Audiostrom an der Quelle ankommt (Eingangszeit), gekennzeichnet durch den RTP-Zeitstempel im Medienpaket, und dem Moment, in dem er das Ziel verlässt (Ausgangszeit). Die Latenz hängt von der Paketzeit, den Ausbreitungs- und Warteschlangenverzögerungen, dem Overhead bei der Paketverarbeitung und der Pufferung im Zielgerät ab. Die minimale Latenz ist also die kürzeste Paketzeit und die kürzeste Netzweiterleitungszeit, die bei einer Punkt-zu-Punkt-Gigabit-Ethernet-Verbindung mit minimaler Paketgröße weniger als 1 μs betragen kann, in realen Netzen aber das Doppelte der Paketzeit betragen kann.
Kleine Puffer verringern die Latenzzeit, können aber zu Tonausfällen führen, wenn die Mediendaten nicht rechtzeitig ankommen. Unerwartete Änderungen der Netzbedingungen und Jitter bei der Paketkodierung und -verarbeitung können eine längere Pufferung und damit eine höhere Latenz erfordern. Die Ziele müssen einen Puffer verwenden, der das Dreifache der Paketzeit beträgt, empfohlen wird jedoch mindestens das 20-fache der Paketzeit (oder 20 ms, wenn diese kleiner ist). Die Quellen müssen die Übertragung mit einem Jitter von weniger als 17 Paketzeiten (oder 17 ms, wenn kürzer) aufrechterhalten, wobei 1 Paketzeit (oder 1 ms, wenn kürzer) empfohlen wird.
Interoperabilität mit AVB
[Bearbeiten | Quelltext bearbeiten]AES67 kann Medienströme als IEEE 802.1BA AVB zeitkritischen Verkehr der Klassen A und B in unterstützten Netzen mit einer garantierten Latenz von 2 ms bzw. 50 ms transportieren. Die Reservierung von Bandbreite mit dem Stream Reservation Protocol (SRP) legt die Menge des erzeugten Verkehrs durch ein Messintervall von 125 μs bzw. 250 μs fest. Es müssen Multicast-IP-Adressen verwendet werden, allerdings nur mit einer einzigen Quelle, da AVB-Netzwerke nur Ethernet-Multicast-Zieladressen im Bereich von 01:00:5e:00:00:00 bis 01:00:5e:7f:ff:ff unterstützen.
Eine SRP-Talker-Ankündigungsnachricht muss wie folgt abgebildet werden:
| StreamID | A 64-bit globally-unique ID (48-bit Ethernet MAC address of the source and 16-bit unique source stream ID). |
|---|---|
| Stream destination address | Ethernet multicast destination address. |
| VLAN ID | 12-bit IEEE 802.1Q VLAN tag. Default VLAN identifier for AVB streams is 2. |
| MaxFrameSize | The maximum size of the media stream packets, including the IP header but excluding Ethernet overhead. |
| MaxIntervalFrames | Maximum number of frames a source may transmit in one measurement interval. Since allowed packet times are greater than (or equal to) AVB measurement intervals, this is always 1. |
| Data Frame Priority | 3 for Class A, 2 for Class B. |
| Rank | 1 for normal traffic, 0 for emergency traffic. |
Sowohl nach IEEE 1588-2008 als auch nach IEEE 802.1AS kann eine PTP-Uhr als gewöhnliche Uhr (OC), Boundary Clock (BC) oder transparente Uhr (TC) bezeichnet werden, wobei transparente Uhren nach 802.1AS auch einige Boundary-Clock-Funktionen haben. Ein Gerät kann eine oder mehrere dieser Funktionen implementieren. OC kann mit nur einem Port (Netzwerkanschluss) ausgestattet sein, während TC und BC zwei oder mehr Ports haben müssen. BC- und OC-Ports können als Master (Grandmaster) oder als Slave arbeiten. Jedem Anschluss ist ein IEEE 1588-Profil zugeordnet. TC kann zu mehreren Clock-Domänen und Profilen gehören. Diese Bestimmungen ermöglichen die Synchronisierung von IEEE 802.1AS-Taktgebern mit IEEE 1588-2008-Taktgebern, die von AES67 verwendet werden.
Geschichte der Entwicklung
[Bearbeiten | Quelltext bearbeiten]Der Standard wurde von der Audio Engineering Society ab Ende 2010 entwickelt. Der Standard wurde erstmals im September 2013 veröffentlicht. Eine zweite Auflage, die eine Patenterläuterung von Audinate enthielt, wurde im März 2014 veröffentlicht.
Im Mai 2016 veröffentlichte die AES einen Bericht, der die Interoperabilität der Synchronisation zwischen AES67 und SMPTE 2059-2 beschreibt.
Anwendung
[Bearbeiten | Quelltext bearbeiten]Der Standard wurde von Lawo, Axia, AMX (in SVSI-Geräten), Wheatstone, Extron Electronics, Riedel, Ross Video, ALC NetworX, Audinate, Archwave, Digigram, Sonifex, Yamaha, QSC, Neutrik, Attero Tech, Merging Technologies, Gallery SIENNA, Behringer, Tieline implementiert und wird von RAVENNA-fähigen Geräten unter dem AES67 Operational Profile unterstützt.
Produkte
[Bearbeiten | Quelltext bearbeiten]Mit der Zeit wird diese Tabelle zu einer Ressource für die Integration und Kompatibilität von Geräten werden. Die von den einzelnen Geräten unterstützten Erkennungsmethoden sind für die Integration von entscheidender Bedeutung, da die AES67-Spezifikation nicht vorschreibt, wie dies zu geschehen hat, sondern stattdessen eine Vielzahl von Optionen oder Vorschlägen bietet. Außerdem spezifiziert AES67 Multicast und Unicast, aber viele AES67-Geräte unterstützen nur Multicast.
| Anbieter | Produkt | Beschreibung | Betriebssystem | AES67 Modell |
Senden | Empfangen | Multicast | Unicast | Hinweise | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Win
|
MacOS
|
Linux
|
SAP
|
mDNS
/RTSP |
NMOS
|
SAP
|
mDNS
/RTSP |
NMOS
| |||||||
| Merging Technologies |
Virtual Audio Device[1] | Ravenna/AES67 drivers | Ja |
Ja [2] |
Ja [3] |
Ravenna AES67 | Ja | Ja | Ja | Ja | Ja | Ja | free | ||
| ALC Networks | Virtual Sound Card[4] | Ravenna/AES67 WDM driver | Ja | Ravenna AES67 | Ja | free | |||||||||
| RAV2SAP[5] | AES67 Discovery Tools | Ja | Ravenna AES67 | Ja | Ja | Ja | free | ||||||||
| Sienna | AES67 to NDI Gateway[6] | AES67 to NDI Gateway | Ja | Ja | Ja | Native AES67 | Ja | Ja | Ja | Ja | |||||
| NDI to AES67[7] | NDI to AES67 Sender | Ja | Ja | Native AES67 | Ja | Ja | Ja | Ja | |||||||
| Lawo | VRX4[8] | Audio Mixer | Ja | Ravenna AES67 | Ja | ||||||||||
| Hasseb | AoE[9] | AES67 Interface: analog and optical |
Native AES67 | Ja | Ja | Ja | Ja | ||||||||
| QSC | DSP, Amplifiers[10] | various | Q-SYS AES67 | Ja | Ja | Ja | |||||||||
| AXIA | Various[11] | various | Livewire+ AES67 | Ja | Ja | ||||||||||
| Yamaha | Mixers[12] | various | Dante AES67 | Ja | Ja | Nein | Ja | ||||||||
| Attero Tech | Endpoints[13] | Endpoints | Attero AES67 | Ja | Ja | Nein | Ja | ||||||||
| SoundTube Entertainment |
Various[14] | Various | Dante AES67 | Ja | Ja | Nein | Ja | ||||||||
| Behringer | Wing[15] | Digital mixer | Dante AES67 | Ja | Ja | Nein | Ja | ||||||||
| Tieline | Gateway, Gateway 4[16] | Audio Codecs | Ja | Ravenna AES67, Livewire+, WheatNet-IP |
Ja | Ja | Ja | Ja | Ja | Ja | |||||
Quellen
[Bearbeiten | Quelltext bearbeiten]- ↑ Merging Technologies: Merging Technologies | Horus & Hapi Mic-Pre & AD/DA for 3rd party DAWs. In: www.merging.com.
- ↑ Merging Technologies: Merging Technologies | Networked Audio | AES67 V.A.D. Standard. In: www.merging.com.
- ↑ Merging Technologies: Merging Technologies | ALSA RAVENNA AES67 Linux Driver. In: www.merging.com.
- ↑ Free version of RAVENNA Virtual Sound Card for Windows now available for download! In: RAVENNA IP-based Media Network. 13. September 2013.
- ↑ RAVENNA-2-SAP AES67 Connection Management Converter. In: RAVENNA IP-based Media Network. 2. August 2019.
- ↑ AES67. In: www.sienna-tv.com.
- ↑ NDIProcessor. In: www.sienna-tv.com.
- ↑ VRX4 Virtual Radio Mixer Software.
- ↑ Audio Over Ethernet Pro. In: hasseb.fi.
- ↑ Q-SYS Cores - Products, Peripherals & Accessories - Q-SYS Ecosystem - Products - Systems - QSC. In: www.qsc.com.
- ↑ Livewire+ AES67 AoIP Networking. In: www.telosalliance.com.
- ↑ Connecting Yamaha Dante devices with other AES67 devices. Yamaha
- ↑ AES67 Audio Networking Quick Start Guide. In: www.atterotech.com.
- ↑ Series. In: Soundtube Entertainment. Abgerufen am 11. April 2019 (amerikanisches Englisch).
- ↑ Behringer | Product | WING.
- ↑ Gateway Wins Prestigious Award. Tieline
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „soundandpicture“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „radioworld“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „ravenna_aes67“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „aessc“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „infocomm“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „svg“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „prosoundweb“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „infocomm2016“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „radio“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „rwaes67“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „Harvey“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „Installation“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „iabm“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „TVT“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „Digital Production“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „RadioWorld MNA“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „psnplugfest“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „rAVe“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „archwave“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „coveloz-avnu-aes67“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „aespf2015“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „aespf2014“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „aesinit“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „aesr16“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „YamahaPSW“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „sonifex“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „qsc“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „aespf2017“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „Attero“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „RapidTV“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „Merging“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „MergingAudioMedia2“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „AES67-2018“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „coveloz2016“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „annexc“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „annexd“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „AES67_101-2018“ weist keinen Inhalt auf.
Referenzfehler: Das in <references> Gruppe „“ definierte <ref>-Tag mit dem Namen „Tieline“ weist keinen Inhalt auf.
Externe Links
[Bearbeiten | Quelltext bearbeiten]- Media Networking Alliance
- AIMS Alliance
- Patrick Killiany: Introduction to AES67. Hrsg.: Yamaha Commercial Audio Systems. Oktober 2016 (youtube.com [abgerufen am 12. November 2022]).
- Open-source AES67 implementation (proposed)
- Open-source AES67 implementation for Linux
- Open-source AES67 Monitoring Software
Vorlage:Digital audio and video protocols [[Kategorie:Datenübertragungsstandard]] [[Kategorie:Audio Engineering Society]] [[Kategorie:Audio-Netzwerk-Protokolle]] [[Kategorie:Netzwerkprotokoll]]