Table of Contents
Advertisement
Quick Links
AES67 P
RACTICAL
Content
1 Basic Principles of AES67 ................................................................................................ 2
1.1 Synchronization ........................................................................................................................ 2
1.2 Multicast packet transport . ....................................................................................................... 2
1.3 Quality of Service . ..................................................................................................................... 3
1.4 Session information .................................................................................................................. 4
2 Guidelines for Configuration of an AES67 System ............................................................. 5
2.1 System planning ....................................................................................................................... 5
2.2 Device configuration . .............................................................................................................. 1 1
2.3 Check for proper synchronization (PTP) . ................................................................................ 1 2
2.4 Stream configuration . ............................................................................................................. 1 4
3 Outlook on emerging Technologies and Industry Standards ............................................ 26
3.1 ANEMAN . ................................................................................................................................ 2 6
3.2 NMOS . ..................................................................................................................................... 2 6
3.3 SMPTE ST 2110 ....................................................................................................................... 2 7
4 Conclusion ................................................................................................................... 28
Abstract
AES67 is a standard for high-performance audio-over-IP interoperability. By implementing the
standards definitions and requirements, devices otherwise adhering to specific AoIP protocols that
don't interoperate with each other (i.e. Dante, Livewire, QLAN or RAVENNA) can establish direct
connectivity and become interoperable.
However, while the standard defines what protocols and functions need to be supported, it still leaves
various choices open to the implementer and - by nature - doesn't serve very well as a user's guide;
thus, some background knowledge on networking in general and on AoIP-related topics in particular
is certainly helpful when planning for an AES67 setup.
This guide explains some of the choices and ambiguities left open by the standard and describes how
to circumvent the most commonly observed obstacles when setting up an AES67 network.
G
UIDE
Page 1 of 28
AES67 Practical Guide
Advertisement
Table of Contents
Summary of Contents for Ravenna AES67
-
Page 1: Table Of Contents
AES67 is a standard for high-performance audio-over-IP interoperability. By implementing the standards definitions and requirements, devices otherwise adhering to specific AoIP protocols that don’t interoperate with each other (i.e. Dante, Livewire, QLAN or RAVENNA) can establish direct connectivity and become interoperable. -
Page 2: Basic Principles Of Aes67
While other AoIP solutions offer enhanced functionality (i.e. stream & device discovery, GPIO transport etc.), AES67 has deliberately not defined any requirements in this respect, because they are not required to establish interoperability on the most basic level. Furthermore, various industry... -
Page 3: Quality Of Service
Managed switches provide multicast traffic management through IGMP support. With IGMP, registered multicast packets are forwarded to their designation ports only. Consequently, all AES67 nodes are required to support IGMPv2 which is used to tell the network which streams are to be received. -
Page 4: Session Information
While a number of protocols exist to announce available streams and transport the related SDP data, the creators of the AES67 standard felt that it would have been too stringent to actually mandate for a specific method; instead, they decided to just mention some... -
Page 5: Guidelines For Configuration Of An Aes67 System
2.1.1.2 Topology While AES67 is strictly based on IP and can thus run on any “standard” network topology, it is always a good rule to minimize the number of switches (“hops”) any particular stream will have to navigate in the final network. A small network may consist of only one switch, which of course makes configuration relatively easy. - Page 6 AES67 Practical Guide terms like “backplane speed” or “non-blocking switch fabric” etc. if you expect a high load on your switch. 2.1.1.4 “Green” is evil While preserving energy is usually a good idea, it impedes proper operation of any low latency real- time audio-over-IP technology.
- Page 7 3 DiffServ QoS. Once enabled, check the priority assignments – a managed switch usually has at least 4 priority queues per egress port and AES67 operating with the recommended / default parameters requires this configuration: •...
- Page 8 Default profile are 2^1 and 2^-1 - we recommend setting the SYNC message rate to 2^-1 for faster settlement and better stability. AES67 also defines its own PTP profile, the Media profile. If all AES67 devices on the network support this profile (this is not a requirement), you can reduce the SYNC message interval down to 2^-4 –...
- Page 9 AES67 Practical Guide • DELAY REQUEST intervals: no need to deviate from the default values (2^0) either (unless you know what you are doing). Keep the delay measurement mode configured to end-to-end (E2E) delay measurement. 2.1.5.2 BMCA parameters For best synchronization results, you want to make sure that the best available master clock on the network is actually taking this role.
- Page 10 AES67 device. For this reason, some device manufacturers have decided to include SAP support. Some AES67 devices have default Prio1 values of 248 which usually will result in those devices not becoming GM, unless there is absolutely no better GM available on the network. In those cases, check the achievable accuracy of all participating nodes as –...
-
Page 11: Device Configuration
RAV2SAP is a Windows application which needs to run on a PC which is connected to the audio network. RAV2SAP only monitors and transmits discovery and SDP-related data traffic, no audio is passed through the PC (unless your PC also hosts an AES67-capable virtual sound card). Device configuration 2.2.1... -
Page 12: Check For Proper Synchronization (Ptp)
Some devices support different sampling rates, but only one may be selected at any given time (usually because a device only has one clock circuitry). AES67 calls for support of 48 kHz, but other sample rates may be used; make sure you select the desired sample rate. Further device-specific parametrization may be required;... - Page 13 The simplest approach would be to unlink devices or network segments which are not relevant to AES67. You could also start building your network from scratch by plugging in devices incrementally and checking each time for proper synchronization.
-
Page 14: Stream Configuration
ALC NetworX. Consult the respective Operating Manuals of other devices to execute these steps accordingly. 2.4.1 AES67 stream format Since the main focus of AES67 is on interoperability, the stream format variations to be supported by all devices are pretty narrow: • Sample rate: 48 kHz •... - Page 15 CREEN SHOT TREAM ROPERTIES PAYLOAD FORMAT SELECTION • Name: assign a meaningful name for this stream (not required by AES67, but helps to identify this stream when discovery is used) • Payload: select from pre-defined stream formats (here: AES67 standard stereo) • Address: enter desired multicast address or leave at “auto”...
- Page 16 ROPERTIES AUDIO CHANNEL ASSIGNMENT Once selected, hit “Apply”. This will create an AES67 stereo stream in L24 / 48 kHz data format from audio channels 7 + 8 with an automatically assigned multicast address. The stream is immediately started and available on the network. The stream packets will reach the first switch where they are dropped unless another device has registered to this stream by IGMP.
- Page 17 In order to connect to this stream, the desired receiver device needs access to the respective SDP data. While AES67 specifies the required SDP data, it does not mandate for a specific method to convey this data. Most AoIP solutions offer means for advertising / discovering available streams and transporting the SDP data automatically.
- Page 18 AES67 Practical Guide 2.4.3.1 SDP data transfer by a common discovery method The streams available on the network will be directly visible in the desired receiver and the SDP data will be transferred when setting up the connection; no further action has to be taken at this stage.
- Page 19 2.4.4 Receiving an AES67 stream Connecting to an existing AES67 stream requires inputting the SDP data of the respective stream to the desired receiver. This can either be done manually or with support of a discovery & connection management method.
- Page 20 AES67 Practical Guide RVSC CREEN SHOT TREAM ROPERTIES TREAM OURCE SELECTION In the “Stream Source” drop-down box, select the desired stream from the list. The related SDP file will automatically be accessed and all relevant parameters are filled-in: Page 20 of 28...
- Page 21 Since the packet time in AES67 is 1 ms, the delay needs to be larger than 48 samples plus sufficient delay to cope with the packet jitter Other devices or AoIP systems may offer predefined (sometimes even system-wide) latency classes like low / medium / high or the equivalent.
- Page 22 AES67 Practical Guide RVSC CREEN SHOT TREAM ROPERTIES CHANNEL ASSIGNMENT Once assigned from the drop-down list, hit “Apply” and the receiver will connect to the selected stream. Page 22 of 28...
- Page 23 AES67 Practical Guide RVSC CREEN SHOT VERVIEW WITH X STREAM CONNECTED The RVSC offers statistic displays where the current packet jitter can be visualized (other devices may offer numerical values to indicate current PDV): RVSC CREEN SHOT STATISTICS WITH PACKET JITTER AND RECEIVER BUFFER UTILIZATION Page 23 of 28...
- Page 24 AES67 Practical Guide 2.4.4.2 Connecting to an AES67 stream manually If a common discovery method is not available, the SDP data has to be entered manually into the receiver. The means on how to enter the data varies among devices; a device may either accept the SDP data record as a whole (effectively using copy &...
- Page 25 AES67 Practical Guide Hit the “Show raw SDP” field again, apply desired latency setting and assign channels as in the previous example and hit “Apply”. The stream is now being connected to and it shows up with the edited name in the Rx section of the overview screen:...
-
Page 26: Outlook On Emerging Technologies And Industry Standards
AES67 devices much like Dante controller does for Dante. However, because of the wide range of AES67 devices, compatibility with ANEMAN is achieved on a per manufacturer basis. Several manufacturers have already boarded the project started by Digigram and Merging and many more are coming. -
Page 27: Smpte St 2110
Transport of linear PCM audio data will be defined in ST 2110-30. While ST 2110-30 defines a few minor constraints with respect to AES67, it is safe to say as of today that any AES67 device will be ST 2110-30- compliant. -
Page 28: Conclusion
AES67 Practical Guide 4 Conclusion As we said at the beginning, while the AES67 standard defines the protocols and functions to be supported, it still leaves various choices open to implementers, which necessitates some background knowledge on networking in general and on AoIP-related topics in particular in order to get past first base.