AES67

Last updated

AES67
Manufacturer Info
Manufacturer Audio Engineering Society
Development dateSeptember 2013;10 years ago (September 2013) [1]
Network Compatibility
Switchable Yes
Routable Yes
Ethernet data rates Agnostic
Audio Specifications
Minimum latency 125 μs to 4 ms
Maximum channels per link120
Maximum sampling rate 48, 44.1, or 96 kHz [1]
Maximum bit depth 16 or 24 bits [1]

AES67 is a technical standard for audio over IP and audio over Ethernet (AoE) interoperability. The standard was developed by the Audio Engineering Society and first published in September 2013. It is a layer 3 protocol suite based on existing standards and is designed to allow interoperability between various IP-based audio networking systems such as RAVENNA, Livewire, Q-LAN and Dante.

Contents

AES67 promises interoperability between previously competing networked audio systems [2] and long-term network interoperation between systems. [3] It also provides interoperability with layer 2 technologies, like Audio Video Bridging (AVB). [4] [5] [6] Since its publication, AES67 has been implemented independently by several manufacturers and adopted by many others.

Overview

AES67 defines requirements for synchronizing clocks, setting QoS priorities for media traffic, and initiating media streams with standard protocols from the Internet protocol suite. AES67 also defines audio sample format and sample rate, supported number of channels, as well as IP data packet size and latency/buffering requirements.

The standard calls out several protocol options for device discovery but does not require any to be implemented. Session Initiation Protocol is used for unicast connection management. No connection management protocol is defined for multicast connections.

Synchronization

AES67 uses IEEE 1588-2008 Precision Time Protocol (PTPv2) for clock synchronisation. For standard networking equipment, AES67 defines configuration parameters for a "PTP profile for media applications", based on IEEE 1588 delay request-response sync and (optionally) peer-to-peer sync (IEEE 1588 Annexes J.3 and J4); event messages are encapsulated in IPv4 packets over UDP transport (IEEE 1588 Annex D). Some of the default parameters are adjusted, specifically, logSyncInterval and logMinDelayReqInterval are reduced to improve accuracy and startup time. Clock Grade 2 as defined in AES11 Digital Audio Reference Signal (DARS) is signaled with clockClass.

Network equipment conforming to IEEE 1588-2008 uses default PTP profiles; for video streams, SMPTE 2059-2 PTP profile can be used.

In AVB/TSN networks, synchronization is achieved with IEEE 802.1AS profile for Time-Sensitive Applications.

The media clock is based on synchronized network time with an IEEE 1588 epoch (1 January 1970 00:00:00 TAI). Clock rates are fixed at audio sampling frequencies of 44.1 kHz, 48 kHz and 96 kHz (i.e. thousand samples per second). RTP transport works with a fixed time offset to network clock.

Transport

Media data is transported in IPv4 packets and attempts to avoid IP fragmentation.

Real-time Transport Protocol with RTP Profile for Audio and Video (L24 and L16 formats) is used over UDP transport. RTP payload is limited to 1460 bytes, to prevent fragmentation with default Ethernet MTU of 1500 bytes (after subtracting IP/UDP/RTP overhead of 20+8+12=40 Bytes). [7] Contributing source (CSRC) identifiers and TLS encryption are not supported.

Time synchronization, media stream delivery, and discovery protocols may use IP multicasting with IGMPv2 (optionally IGMPv3) negotiation. Each media stream is assigned a unique multicast address (in the range from 239.0.0.0 to 239.255.255.255); only one device can send to this address (many-to-many connections are not supported).

To monitor keepalive status and allocate bandwidth, devices may use RTCP report interval, SIP session timers and OPTIONS ping, or ICMP Echo request (ping).

AES67 uses DiffServ to set QoS traffic priorities in the Differentiated Services Code Point (DSCP) field of the IP packet. Three classes should be supported at a minimum:

QoS classes and DiffServ associations
Class nameTraffic typeDefault DiffServ class (DSCP decimal value)
ClockIEEE 1588-2008 time events *EF (46)
MediaRTP / RTCP media streamsAF41 (34)
Best effortIEEE 1588-2008 signaling, discovery and connection managementDF (0)

250 μs maximum delay may be required for time-critical applications to prevent drops of audio. To prioritize critical media streams in a large network, applications may use additional values in the Assured Forwarding class 4 with low-drop probability (AF41), typically implemented as a weighted round-robin queue. Clock traffic is assigned to the Expedited Forwarding (EF) class, which typically implements strict priority per-hop behavior (PHB). All other traffic is handled on a best effort basis with Default Forwarding.

RTP Clock Source Signalling procedure is used to specify PTP domain and grandmaster ID for each media stream.

Audio encoding

Sample formats include 16-bit and 24-bit Linear PCM with 48 kHz sampling frequency, and optional 24-bit 96 kHz and 16-bit 44.1 kHz. Other RTP audio video formats may be supported. Multiple sample frequencies are optional. Devices may enforce a global sample frequency setting.

Media packets are scheduled according to 'packet time' - transmission duration of a standard Ethernet packet. Packet time is negotiated by the stream source for each streaming session. Short packet times provide low latency and high transmission rate, but introduce high overhead and require high-performance equipment and links. Long packet times increase latencies and require more buffering. A range from 125 μs to 4 ms is defined, though it is recommended that devices shall adapt to packet time changes and/or determine packet time by analyzing RTP timestamps.

Packet time determines RTP payload size according to a supported sample rate. 1 ms is required for all devices. Devices should support a minimum of 1 to 8 channels per stream. [7]

Recommended packet times
Packet timeSamples per packetNotes
44.1 / 48 kHz96 kHz
125 μs612Compatible with AVB Class A
250 μs1224High-performance low-latency operation. Compatible with AVB Class B, interoperable with AVB Class A
333+1⁄3 μs1632Efficient low-latency operation
1 ms4896Required packet time for all devices
4 ms192384Wide area networks, networks with limited QoS capabilities, or interoperability with EBU 3326
Maximum channels per stream
Audio formatPacket time
125 μs250 μs333+1⁄3 μs1 ms4 ms
48 kHz / 16 bit1206045153
48 kHz / 24 bit804030102
96 kHz / 24 bit40201551

Latency

Network latency (link offset) is the time difference between the moment an audio stream enters the source (ingress time), marked by RTP timestamp in the media packet, and the moment it leaves the destination (egress time). Latency depends on packet time, propagation and queuing delays, packet processing overhead, and buffering in the destination device; thus minimum latency is the shortest packet time and network forwarding time, which can be less than 1 μs on a point-to-point Gigabit Ethernet link with minimum packet size, but in real-world networks could be twice the packet time.

Small buffers decrease latency but may result in drops of audio when media data does not arrive on time. Unexpected changes to network conditions and jitter from packet encoding and processing may require longer buffering and therefore higher latency. Destinations are required to use a buffer of 3 times the packet time, though at least 20 times the packet time (or 20 ms if smaller) is recommended. Sources are required to maintain transmission with jitter of less than 17 packet times (or 17 ms if shorter), though 1 packet time (or 1 ms if shorter) is recommended.

Interoperability with AVB

AES67 may transport media streams as IEEE 802.1BA AVB time-sensitive traffic Classes A and B on supported networks, with guaranteed latency of 2 ms and 50 ms respectively. Reservation of bandwidth with the Stream Reservation Protocol (SRP) specifies the amount of traffic generated through a measurement interval of 125 μs and 250 μs respectively. Multicast IP addresses have to be used, though only with a single source, as AVB networks only support Ethernet multicast destination addressing in the range from 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff.

An SRP talker advertise message shall be mapped as follows:

Talker advertise message
StreamIDA 64-bit globally-unique ID (48-bit Ethernet MAC address of the source and 16-bit unique source stream ID).
Stream destination addressEthernet multicast destination address.
VLAN ID12-bit IEEE 802.1Q VLAN tag. Default VLAN identifier for AVB streams is 2.
MaxFrameSizeThe maximum size of the media stream packets, including the IP header but excluding Ethernet overhead.
MaxIntervalFramesMaximum 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 Priority3 for Class A, 2 for Class B.
Rank1 for normal traffic, 0 for emergency traffic.

Under both IEEE 1588-2008 and IEEE 802.1AS, a PTP clock can be designated as an ordinary clock (OC), boundary clock (BC) or transparent clock (TC), though 802.1AS transparent clocks also have some boundary clock capabilities. A device may implement one or more of these capabilities. OC may have as few as one port (network connection), while TC and BC must have two or more ports. BC and OC ports can work as a master (grandmaster) or a slave. An IEEE 1588 profile is associated with each port. TC can belong to multiple clock domains and profiles. These provisions make it possible to synchronize IEEE 802.1AS clocks to IEEE 1588-2008 clocks used by AES67.

Development history

The standard was developed by the Audio Engineering Society beginning at the end of 2010. [8] The standard was initially published September 2013. [9] [10] [11] [12] A second printing which added a patent statement from Audinate was published in March 2014.

The Media Networking Alliance was formed in October 2014 to promote adoption of AES67. [13]

In October 2014 a plugfest was held to test interoperability achieved with AES67. [14] [15] A second plugfest was conducted in November 2015 [16] and third in February 2017. [17]

An update to the standard including clarifications and error corrections was issued in September 2015. [1]

In May 2016, the AES published a report describing synchronization interoperability between AES67 and SMPTE 2059-2. [18]

In June 2016, AES67 audio transport enhanced by AVB/TSN clock synchronisation and bandwidth reservation was demonstrated at InfoComm 2016. [19]

In September 2017, SMPTE published ST 2110, a standard for professional video over IP. [20] ST 2110-30 uses AES67 as the transport for audio accompanying the video. [21]

In December 2017 the Media Networking Alliance merged with the Alliance for IP Media Solutions (AIMS) combining efforts to promote standards-based network transport for audio and video. [22]

In April 2018 AES67-2018 was published. The principal change in this revision is addition of a protocol implementation conformance statement (PICS). [23]

The AES Standards Committee and AES67 editor, Kevin Gross, were recipients of a Technology & Engineering Emmy Award in 2019 for the development of synchronized multi-channel uncompressed audio transport over IP networks. [24]

Adoption

The standard has been implemented by Lawo, [25] Digisynthetic, [26] Axia, [27] AMX (in SVSI devices), Wheatstone, [28] [29] Extron Electronics, Riedel, [30] Ross Video, [31] [32] ALC NetworX, [33] Audinate, [34] Archwave, [35] Digigram, [36] Sonifex, [37] Aqua Broadcast, [38] Yamaha, [39] QSC, [40] Neutrik, Attero Tech, [41] Merging Technologies, [42] [43] Gallery SIENNA, [44] Behringer, [45] Tieline [46] and is supported by RAVENNA-enabled devices under its AES67 Operational Profile. [47]

Shipping products

Over time this table will grow to become a resource for integration and compatibility between devices. The discovery methods supported by each device are critical for integration since the AES67 specification does not stipulate how this should be done, but instead provides a variety of options or suggestions. Also, AES67 specifies multicast and unicast but many AES67 devices only support multicast.

VendorProductDescriptionOSAES67
Model		SendReceive
Multicast
Unicast
Notes
Win
MacOS
Linux
SAP
mDNS
/RTSP
NMOS
SAP
mDNS
/RTSP
NMOS
Merging
Technologies		Virtual Audio Device [48] Ravenna/AES67 driversGreen check.svg
Green check.svg
[49] 		Green check.svg
[50] 		Ravenna AES67Green check.svgGreen check.svgGreen check.svgGreen check.svgGreen check.svgGreen check.svgfree
ALC NetworksVirtual Sound Card [51] Ravenna/AES67 WDM driverGreen check.svgRavenna AES67Green check.svgfree
RAV2SAP [52] AES67 Discovery ToolsGreen check.svgRavenna AES67Green check.svgGreen check.svgGreen check.svgfree
SiennaAES67 to NDI Gateway [44] AES67 to NDI GatewayGreen check.svgGreen check.svgGreen check.svgNative AES67Green check.svgGreen check.svgGreen check.svgGreen check.svg
NDI to AES67 [53] NDI to AES67 SenderGreen check.svgGreen check.svgNative AES67Green check.svgGreen check.svgGreen check.svgGreen check.svg
LawoVRX4 [54] Audio MixerGreen check.svgRavenna AES67Green check.svg
HassebAoE [55] AES67 Interface:
analog and optical		Native AES67Green check.svgGreen check.svgGreen check.svgGreen check.svg
QSCDSP, Amplifiers [56] variousQ-SYS AES67Green check.svgGreen check.svgGreen check.svg
AXIAVarious [57] variousLivewire+ AES67Green check.svgGreen check.svg
YamahaMixers [58] variousDante AES67Green check.svgGreen check.svgGreen check.svgRed x.svg
Aqua BroadcastCobra FM Transmitters [38] AES67 Dante inputDante AES67Green check.svg
Attero TechEndpoints [59] EndpointsAttero AES67Green check.svgGreen check.svgGreen check.svgRed x.svg
SoundTube
Entertainment		Various [60] VariousDante AES67Green check.svgGreen check.svgGreen check.svgRed x.svg
BehringerWing [45] Digital mixerDante AES67Green check.svgGreen check.svgGreen check.svgRed x.svg
TielineGateway, Gateway 4 [61] Audio CodecsGreen check.svgRavenna AES67,
Livewire+,
WheatNet-IP
[ clarification needed ]		Green check.svgGreen check.svgGreen check.svgGreen check.svgGreen check.svgGreen check.svg
CiscoCollaboration devices [62] Interoperability with microphones and speakersNative AES67Green check.svgGreen check.svgGreen check.svg
DigisyntheticDL08 [63] AES67+DSP Network ModuleGreen check.svgGreen check.svgDigisyn Link AES67Green check.svgGreen check.svgGreen check.svg
2-Channel Virtual Sound Card [64] Digisyn Link/AES67 WDM driverGreen check.svgDigisyn Link AES67Green check.svgGreen check.svgGreen check.svgfree

Related Research Articles

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Session Announcement Protocol (SAP) is an experimental protocol for advertising multicast session information. SAP typically uses Session Description Protocol (SDP) as the format for Real-time Transport Protocol (RTP) session descriptions. Announcement data is sent using IP multicast and the User Datagram Protocol (UDP).

<span class="mw-page-title-main">Universal Plug and Play</span> Set of networking protocols

Universal Plug and Play (UPnP) is a set of networking protocols on the Internet Protocol (IP) that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices, to seamlessly discover each other's presence on the network and establish functional network services. UPnP is intended primarily for residential networks without enterprise-class devices.

<span class="mw-page-title-main">VoIP phone</span> Phone using one or more VoIP technologies

A VoIP phone or IP phone uses voice over IP technologies for placing and transmitting telephone calls over an IP network, such as the Internet. This is in contrast to a standard phone which uses the traditional public switched telephone network (PSTN).

The Precision Time Protocol (PTP) is a protocol used to synchronize clocks throughout a computer network. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. PTP is employed to synchronize financial transactions, mobile phone tower transmissions, sub-sea acoustic arrays, and networks that require precise timing but lack access to satellite navigation signals.

In audio and broadcast engineering, Audio over Ethernet is the use of an Ethernet-based network to distribute real-time digital audio. AoE replaces bulky snake cables or audio-specific installed low-voltage wiring with standard network structured cabling in a facility. AoE provides a reliable backbone for any audio application, such as for large-scale sound reinforcement in stadiums, airports and convention centers, multiple studios or stages.

CobraNet is a combination of software, hardware, and network protocols designed to deliver uncompressed, multi-channel, low-latency digital audio over a standard Ethernet network. Developed in the 1990s, CobraNet is widely regarded as the first commercially successful audio-over-Ethernet implementation.

Audio over IP (AoIP) is the distribution of digital audio across an IP network such as the Internet. It is used increasingly to provide high-quality audio feeds over long distances. The application is also known as audio contribution over IP (ACIP) in reference to the programming contributions made by field reporters and remote events. Audio quality and latency are key issues for contribution links. In the past, these links have made use of ISDN services but these have become increasingly difficult or expensive to obtain.

Stream Reservation Protocol (SRP) is an enhancement to Ethernet that implements admission control. In September 2010 SRP was standardized as IEEE 802.1Qat which has subsequently been incorporated into IEEE 802.1Q-2011. SRP defines the concept of streams at layer 2 of the OSI model. Also provided is a mechanism for end-to-end management of the streams' resources, to guarantee quality of service (QoS).

Ravenna is a technology for real-time transport of audio and other media data over IP networks. Ravenna was introduced on September 10, 2010 at the International Broadcasting Convention in Amsterdam. Ravenna can operate on most existing network infrastructures using standard networking technology. Performance and capacity scale with network performance. Ravenna is designed to match broadcasters' requirements for low latency, full signal transparency and high reliability. Fields of application include in-house signal distribution for broadcasting houses and other fixed installations, flexible setups at venues and live events, outside broadcasting support, and inter-studio links across wide area network links and production facilities.

Livewire is an audio-over-IP system created by Axia Audio, a division of Telos Alliance. Its primary purpose is routing and distributing broadcast-quality audio in radio stations.

RTP-MIDI is a protocol to transport MIDI messages within Real-time Transport Protocol (RTP) packets over Ethernet and WiFi networks. It is completely open and free, and is compatible both with LAN and WAN application fields. Compared to MIDI 1.0, RTP-MIDI includes new features like session management, device synchronization and detection of lost packets, with automatic regeneration of lost data. RTP-MIDI is compatible with real-time applications, and supports sample-accurate synchronization for each MIDI message.

Avnu Alliance is a consortium of member companies working together to create an interoperable ecosystem of low-latency, time-synchronized, highly reliable networking devices using the IEEE open standard, Time-Sensitive Networking (TSN) and its Pro AV networking protocol, Milan. Avnu Alliance creates comprehensive certification programs to ensure interoperability of network devices. In the Professional Audio Video (AV) industry, Alliance member companies worked together to develop Milan: a standards-based, user-driven deterministic network protocol for professional media, that through certification, assures devices will work together at new levels of convenience, reliability, and functionality. Milan™ is a standards-based deterministic network protocol for real time media. Avnu Members may use the Avnu-certified or Milan-certified logo on devices that pass the conformance tests from Avnu. Not every device based on AVB or TSN is submitted for certification to the Avnu Alliance. The lack of the Avnu logo does not necessarily imply a device is incompatible with other Avnu-certified devices. The Alliance, in conjunction with other complimentary standards bodies and alliances, provides a united network foundation for use in professional AV, automotive, industrial control and consumer segments.

Time-Sensitive Networking (TSN) is a set of standards under development by the Time-Sensitive Networking task group of the IEEE 802.1 working group. The TSN task group was formed in November 2012 by renaming the existing Audio Video Bridging Task Group and continuing its work. The name changed as a result of the extension of the working area of the standardization group. The standards define mechanisms for the time-sensitive transmission of data over deterministic Ethernet networks.

The following is a comparison of audio over Ethernet and audio over IP audio network protocols and systems.

SMPTE 2059 is a standard from the Society of Motion Picture and Television Engineers (SMPTE) that describes how to synchronize video equipment over an IP network. The standard is based on IEEE 1588-2008. SMPTE 2059 is published in two parts on 9 April 2015:

SMPTE 2110 is a suite of standards from the Society of Motion Picture and Television Engineers (SMPTE) that describes how to send digital media over an IP network.

Deterministic Networking (DetNet) is an effort by the IETF DetNet Working Group to study implementation of deterministic data paths for real-time applications with extremely low data loss rates, packet delay variation (jitter), and bounded latency, such as audio and video streaming, industrial automation, and vehicle control.

<span class="mw-page-title-main">Audio Video Bridging</span> Specifications for synchronized, low-latency streaming through IEEE 802 networks

Audio Video Bridging (AVB) is a common name for the set of technical standards which provide improved synchronization, low-latency, and reliability for switched Ethernet networks. AVB embodies the following technologies and standards:

References

  1. 1 2 3 4 "AES67-2013: AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability". Audio Engineering Society. September 11, 2013. Retrieved February 11, 2014.
  2. ↑ Steve Harvey (June 27, 2014). "NAB Show Product Review: Audio". TV Technology. Archived from the original on March 3, 2016. Retrieved June 29, 2014.
  3. ↑ Dave Davies (July 22, 2014). "Mark Yonge on the new dawn for networking". Installation. Archived from the original on July 28, 2014. Retrieved July 23, 2014.{{cite journal}}: Cite journal requires |journal= (help)
  4. ↑ AES67-2018 – Annex C (Informative) – AVB network transport
  5. ↑ AES67-2018 – Annex D (Informative) – Interfacing to IEEE 802.1AS clock domains
  6. ↑ Nestor Amaya (March 2016). "AES67 for Audio Production: Background, Applications and Challenges" (PDF).
  7. 1 2 AES67-101: The Basics of AES67. Anthony P. Kuzub
  8. ↑ AES-X192 initiation, Audio Engineering Society, December 1, 2010
  9. ↑ Dan Daley (October 2013). "AES Throws New Audio Networking Standard Into the Ring" . Retrieved February 11, 2014.
  10. ↑ Dan Daley (September 16, 2013). "AES Announces AES67-2013 Networked Audio-Over-IP Interoperability Standard" . Retrieved February 11, 2014.{{cite journal}}: Cite journal requires |journal= (help)
  11. ↑ "AES Announces New Networked Audio-Over-IP Interoperability Standard: AES67-2013". ProSoundWeb. September 12, 2013. Archived from the original on February 22, 2014. Retrieved February 11, 2014.
  12. ↑ "AES Announces New Networked Audio-Over-IP Interoperability Standard: AES67-2013". Radio. September 16, 2013. Archived from the original on February 17, 2017. Retrieved February 11, 2014.{{cite journal}}: Cite journal requires |journal= (help)
  13. ↑ "AES Show Introduces Media Networking Alliance". Radio World. October 6, 2014. Archived from the original on September 24, 2015. Retrieved November 11, 2014.
  14. ↑ Jon Chapple (November 27, 2014), "AES Standards Committee, EBU test AES67 at PlugFest", PSN Europe, archived from the original on December 4, 2014, retrieved November 29, 2014
  15. ↑ AES-R12-2014: Standards project report - AES67 Interoperability PlugFest - Munich 2014, Audio Engineering Society, November 24, 2014
  16. ↑ AES-R15-2015: Standards project report - AES67 Interoperability PlugFest - Washington 2015, Audio Engineering Society, January 2, 2016
  17. ↑ AES-R17-2017: Standards project report - AES67 Interoperability PlugFest - London 2017, Audio Engineering Society, April 28, 2017
  18. ↑ AES-R16-2016: AES Standards Report - PTP parameters for AES67 and SMPTE ST 2059-2 interoperability, Audio Engineering Society, May 2, 2016
  19. ↑ Joao Martins (June 16, 2016). "AVB/TSN Momentum and AES67/AVB Harmony at InfoComm 2016" . Retrieved December 8, 2016.
  20. ↑ "SMPTE Approves ST 2110-30 Standards for Professional Media Over Managed IP Networks". Archived from the original on December 1, 2017. Retrieved November 30, 2017.
  21. ↑ Leigh Whitcomb (June 30, 2017), "Audio for Television: How AES67 and Uncompressed 2022/2110/TR03 Video Fit Together", SMPTE Motion Imaging Journal, SMPTE, 126 (5): 35–40, doi:10.5594/JMI.2017.2703479
  22. ↑ Michelle Clancy (December 28, 2017), AIMS, Media Networking Alliance merge, Rapid TV News
  23. ↑ "AES67-2018: AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability Published". April 24, 2018.
  24. ↑ "71st Award Recipients – the Emmys".
  25. ↑ Lawo. "Lawo supports successful AES67 Interoperability Demo during AES Convention in New York". www.lawo.com. Archived from the original on October 26, 2017. Retrieved October 26, 2017.
  26. ↑ "Digisyn Link - The Ultimate AES67 Audio over IP Solution". Digisynthetic | 顶力. Retrieved October 22, 2023.
  27. ↑ "Axia Announces First Broadcast Product with AES67 Compliance". Sound & Picture. November 14, 2013. Retrieved February 11, 2014.{{cite journal}}: Cite journal requires |journal= (help)
  28. ↑ "IP Audio Takes a Big Step Forward". Radio World . February 21, 2014. Archived from the original on September 24, 2015. Retrieved June 18, 2014.
  29. ↑ Steve Harvey (August 11, 2014). "Standardizing AoIP is Enabling Interoperability". TV Technology. Archived from the original on August 13, 2014. Retrieved August 13, 2014.
  30. ↑ "Reidel to make a splash at SATIS 2014". Digital Production. October 29, 2014. Retrieved November 11, 2014.
  31. ↑ "BACH ST2110 AES67 Audio Networking Modules, Chips, and Software".
  32. ↑ "Coveloz Bach: World's first AES67 endpoint to gain AVnu Certification'". Pro-Audio Central. January 6, 2016. Retrieved February 6, 2016.
  33. ↑ "ALC NetworX Shows Ravenna, AES67". Radio World . January 29, 2014. Archived from the original on September 24, 2015. Retrieved February 11, 2014.
  34. ↑ Michael Williams (April 8, 2015), Audinate Announces Availability of Firmware Update to Support AES67, rAVe
  35. ↑ Jon Chapple (February 11, 2015). "ISE 2015: Archwave's AES67 networking modules provide 'MIDI 3.0 on steroids'". PSN Europe. Archived from the original on April 16, 2015. Retrieved May 2, 2015.
  36. ↑ "Digigram to Showcase RAVENNA/AES67 Compatibility of IQOYA IP Audio Codec Line at IBC2014". IABM. August 5, 2014. Archived from the original on August 8, 2014. Retrieved August 5, 2014.
  37. ↑ "Sonifex Press Release - Sonifex joins the RAVENNA alliance". Archived from the original on February 7, 2016. Retrieved May 17, 2016.
  38. 1 2 "Cobalt C-1000 / 1000W FM Transmitter". aquabroadcast.co.uk.
  39. ↑ Yamaha Dante Products To Support AES67, ProSoundWeb, September 9, 2016
  40. ↑ "QSC Q-SYS Platform Software Release to Support AES67". QSC. December 7, 2016.
  41. ↑ Attero Tech Ships AES67 Networked Audio Products , retrieved December 17, 2017
  42. ↑ Merging Technologies-Digigram Aneman , retrieved February 20, 2018
  43. ↑ ISE 2017: RAVENNA presenting AES67 demo rack , retrieved February 20, 2018
  44. 1 2 "AES67". www.sienna-tv.com.
  45. 1 2 "Behringer | Product | WING".
  46. ↑ Tieline adds RAVENNA support to Gateway codec family and joins RAVENNA community, Ravenna/ALC NetworX, August 31, 2021
  47. ↑ "RAVENNA & AES67". ALC NetworX. Archived from the original on February 21, 2014. Retrieved February 12, 2014.
  48. ↑ Technologies, Merging. "Merging Technologies | Horus & Hapi Mic-Pre & AD/DA for 3rd party DAWs". www.merging.com.
  49. ↑ Technologies, Merging. "Merging Technologies | Networked Audio | AES67 V.A.D. Standard". www.merging.com.
  50. ↑ Technologies, Merging. "Merging Technologies | ALSA RAVENNA AES67 Linux Driver". www.merging.com.
  51. ↑ "Free version of RAVENNA Virtual Sound Card for Windows now available for download!". RAVENNA IP-based Media Network. September 13, 2013.
  52. ↑ "RAVENNA-2-SAP AES67 Connection Management Converter". RAVENNA IP-based Media Network. August 2, 2019.
  53. ↑ "NDIProcessor". www.sienna-tv.com.
  54. ↑ "VRX4 Virtual Radio Mixer Software".
  55. ↑ "Audio Over Ethernet Pro". hasseb.fi.
  56. ↑ "Q-SYS Cores - Products, Peripherals & Accessories - Q-SYS Ecosystem - Products - Systems - QSC". www.qsc.com.
  57. ↑ "Livewire+ AES67 AoIP Networking". www.telosalliance.com.
  58. ↑ "Connecting Yamaha Dante devices with other AES67 devices". Yamaha.
  59. ↑ "AES67 Audio Networking Quick Start Guide". www.atterotech.com.
  60. ↑ "Series". Soundtube Entertainment. Archived from the original on April 11, 2019. Retrieved April 11, 2019.
  61. ↑ "Gateway Wins Prestigious Award". Tieline.
  62. ↑ "AES67 interoperability on Room Devices". Cisco.
  63. ↑ "DL08/DL16 AES67 Audio Network Module". Digisynthetic | 顶力. Retrieved October 23, 2023.
  64. ↑ "Digisyn Virtual Soundcard". Digisynthetic | 顶力. Retrieved December 27, 2023.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.