AES67 plug fest – a trip to Munich8 February 2016
Here’s a second post from independent consultancy RH Consulting on its rolling plug fest for AES67 – testing different manufacturers’ AES67-compatible equipment.
After rushing into our plug fest and then with Christmas getting in the way, our plug fest has been a little delayed.
On our voyage into AES67 we decided to start with RAVENNA as it’s the only fully fledged protocol that is AES67 compatible out of the box. We got hold of a Lawo Crystal and a Merging HAPI and Pyramix. Merging to Merging worked fine but we struggled to put them together with the Crystal. We crashed the network. We didn’t pay sufficient attention to our switch set up.
In the world of audio networking, switch set up is really important.
Getting the switch set up correct may seem like a complication in comparison to some other audio networking solutions but we later found that this reveals one of the real strengths of RAVENNA. It can be carefully managed in large and complex networks as used in the IT world. How did we discover this? We went on a little trip…
Last week we took a flight to Munich to the HQ of ALC NetworX, the inventors of RAVENNA with an Aladdins cave of RAVENNA devices for us to play with.
We met with Andreas Hildebrand who was a member of the AES67 Task Group and acts as a RAVENNA Evangelist for ALC.
He began by explaining the finer points of audio networking, the AES67 standard and how it all ties together. So let’s start by translating what we learnt into layman’s language!
Audio networking sounds very complicated but in essence it uses techniques and technologies developed and standardised in the IT world. These standards such as Ethernet and IP form the building blocks of how audio networks work, but each solution uses different combinations or implementations of these standards to operate. RAVENNA is a solution based on IT standards and AES67 uses the same standards; and this is where we finally understood the difference between it and other protocols including Dante.
So let’s look at the building blocks of all audio networks.
The first thing to understand is the transport mechanism. This is how the packets of data are formatted to be sent across the network. Different protocols use different methods of doing this, they travel over a layer called UDP which is ideal for real-time media networks. The Audio is transported using a protocol called (Real Time Protocol) RTP over the UDP layer.
You may have heard of another transport mechanism called TCP/IP but that format isn’t used for audio because, put simply, it introduces too much latency.
It’s time to talk about clocking
Just like MADI and other digital audio signals, audio networks need a sample clock to ensure that all your audio is reproduced coherently together. This is why some audio equipment has a BNC connector for the clock. On audio networking gear that clock is sent across the network in parallel to all the other data.
The clock is like a conductor in an Orchestra. Indeed the Cobranet audio networking protocol calls its clock just that, and you had one device in your network called the ‘conductor’.
For clocking, RAVENNA and DANTE rely on a mechanism called Precision Time Protocol (PTP – IEEE 1588) which defines the precise distribution of time over a network. However in the cases above they use different versions of this standard, which are incompatible.
Dante uses version 1 and RAVENNA uses version 2. AES67 also requires version 2. The two versions are incompatible with different message formats. Version 2 is more accurate and can use ‘transparent clocks’ to achieve a more accurate synchronization. What’s a transparent clock? A transparent clock is a switch which can correct for the transmission latency of clock packets, which results in a much better synchronization, specifically on large networks where RAVENNA is typically used.
The use of a GPS timing signal as external reference further improves synchronization accuracy, especially across large sites
You can have a network with multiple GPS receivers and the network will synchronise across different sites because GPS is so accurate. This allows you to create networks across huge distances (Lawo have streamed audio to London from their site in Germany) and it all remains in sync.
Quality of Service
To ensure that real time signals such as audio get there on time IT networks use a system called Quality of Service (QoS). This defines how different types of data are prioritised, the clock is more important followed by the audio data itself. At present the way Dante and RAVENNA do that is slightly different, Q-Lan is different again. (One of the benefits of AVB is that the AVB switch effectively handles this automatically, giving priority to time sensitive data such as audio.)
All audio networking protocols use a method called DiffServ (Differentiated Services) to categorise different traffic flows (i.e. clock and audio traffic). DSCP is a method of tagging different types of traffic to allow DiffServ to organise the priority of different data types. DiffServ needs to be enabled and appropriately configured in the participating switches.
However each protocol uses different tags so they are incompatible with each other.
The current difference is that protocols like Q-Lan and Dante use a fixed method of tagging, whereas with RAVENNA, tagging is customisable by the user. This makes it very friendly in corporate environments. Why is that?
Some IT systems like VoIP have an agreed DSCP scheme, which automatically assigns them to a high priority on a network. Giving another service a high priority can cause conflicts when trying to run VoIP and Audio networking on the same network. The flexibility of RAVENNA allows you to plan a more coherent scheme for different types of real-time audio that is configurable by an IT admin.
If I want to make an international phone call I need to know two things – first the telephone number to call and then we need to agree what language we are going to speak in. The telephone number is the address and the language is the media data format.
In order for two networked devices to send audio to each other they need to know each other’s address. and also how they should manage the connection between each other so they can communicate together.
This is where discovery comes in. Discovery is used to advertise available devices and streams on the network. However, different methods are used.
In native mode, Dante uses a non-disclosed form of Bonjour. In AES67 mode, it uses SAP. RAVENNA always uses Bonjour for discovery (but with disclosed information), but also allows manual configuration.
Bonjour is a very flexible and powerful mechanism for advertisement of different kind of services, while SAP is strictly related and limited to announcing some types of connection.
AES67 does not cover discovery at all and this has been the subject of industry debate.
Which is better?
One of the things you’ll have noticed is that we appear to be saying that RAVENNA is superior to other audio networking protocols. Indeed it offers greater flexibility than all others, and in more ways than mentioned here. However that flexibility comes at a price – it’s much more difficult to configure. RAVENNA definitely isn’t plug and play.
Phew, now we can get back to the easy stuff.
Let’s plug in
To learn about AES67, we thought we’d start with a RAVENNA set up. Following what we learnt above we set up our switch, ensuring we had EEE (Energy Efficient Ethernet) disabled, had set up QoS and correctly configured the processing of multicast traffic.
We then installed RAVENNA Virtual Sound Card onto a PC and connected a Merging Horus to our network.
(Click on diagrams for an enlarged view.)
We first set up a stereo 24 bit 48kHz RAVENNA stream as an output from our media player. RAVENNA gives you the option to create a stream (audio connection) with up to 64 channels. You can receive this stream on any other RAVENNA enabled device connected to the network and RAVENNA allows an unlimited number of these streams dependant on available bandwidth.
On the Horus we enabled RAVENNA as the input to the headphone bus and then went to a special webpage on the Horus and sent the RAVENNA stream coming from VSC to the headphones.
It worked. Our first RAVENNA connection. It doesn’t sound like much but it was a long journey of discovery to get us there.
That’s enough for this week. We’ll add more detail and talk about connecting other devices next week.
We couldn’t resist telling you about a very cool thing we did. We think it’s an audio networking first.
First of all we successfully tested the software by sending and receiving audio between our Mac and the Windows PC running RAVENNA virtual sound card.
The Merging RAVENNA/AES67 virtual audio device then just appeared, as you would expect, as inputs and outputs within Via.
Ticking ‘enable Dante’ on the Merging input of Via then allowed the AES67 input to be sent as Dante to a second Mac also running Via. A simple AES67-Dante bridge was thus created. Interesting times!