Roland Hemming’s Take on Milan


At InfoComm 2018, Avid, Audio Science, Biamp, d&b, l’acoustics, Luminex and Meyer announced the launch of Milan, a new protocol for products using AVB, supported by the Avnu alliance.

The Italian connection

Why does Italy dominate audio networking? Dante and RAVENNA are both acronyms and names. The first was an Italian poet and the second was the Italian city where he died. I haven’t asked why the name Milan was chosen nor have I worked out what the acronym is.

Multimedia Intelligent Local Area Network, Media Integration links And Networking? Avnu help us out here!

The Avnu team filled a room at the 2018 InfoComm show to explain their new initiative. I have commented on digital audio networking for several years and have issued statistics on the adoption of each of the major protocols. I have been generally critical of the approach Avnu has taken.

In November 2017 I wrote what I thought would be my last words on AVB, suggesting that efforts from Avnu members in the ProAV market would be better spent elsewhere.

Not long after, I was informed that ‘something was coming’ and I promised to keep an open mind.

It was a nice presentation from the Avnu team but gave the impression that the rest of us are crawling around in the dirt, barely able to connect anything presumably due to our lack of opposable thumbs.

As soon as the announcement came, I received many requests for my opinion on Milan and its likely impact on digital audio networking.


What is Milan?

Let’s be clear, Milan is an improvement. For those wishing to use AVB, Milan will offer features to improve connectivity.

Milan is not a new standard. AVB is still there underneath.

AVB is an IEEE standard and provides precise synchronisation of data across a network. With AVB, at the point of sending a packet of data, you know when it is going to arrive at its destination. This is what they mean by deterministic. This can be a huge benefit for people like us working in audio and video.

Furthermore, AVB divides the network bandwidth into media and other streams, guaranteeing bandwidth for media, whilst still allowing other data to pass through. You could consider this an advanced QoS.

Since it is an IEEE standard, AVB is free and open if you have the ability to adopt it into your products, and there’s no license cost. RAVENNA and AES67 can also be adopted license-free.

With AVB, RAVENNA and AES67 there are also companies who can help manufacturers with implementation or provide ready-made cards. With Dante, it's a single vendor route, normally with their ready-made cards.

In many ways we have been wrong to compare AVB with Dante and RAVENNA. AVB is an underlying technology, whereas Dante and RAVENNA are protocols – solutions if you like.

Currently, if you connect two AVB audio devices together there is no guarantee that they will pass audio between them. Indeed, there are proprietary implementations using AVB between a single manufacturer’s products. Where cross connectivity has been offered, that doesn’t guarantee the connection is universal. For example, Biamp Tesira can connect using AVB to Lab.gruppen D Series amplifiers (the ‘T’ versions), but that connection only works between those two products - you can’t connect any other AVB device to those streams.

Milan provides audio companies with some rules to ensure that audio streams will be understood by the receiving device. This is similar to RAVENNA in that it creates profiles.

Profiles determine the bit depth, sampling frequency, clock, number of channels and other criteria too.

RAVENNA can support a huge number of profiles with very many options depending on what you are trying to do with your audio. One RAVENNA profile is AES67.

If you want to think in those terms, then Dante I suppose has multiple profiles – 48Khz, 96Khz and 192Khz. One option is AES67 mode, allowing you to send AES67 compliant streams. Dante offers users fewer options in an effort to keep things simple.

Milan has one compulsory profile and two optional ones for manufacturers to adopt – very simple indeed.

Milan gives guidelines to ensure connectivity between Milan compliant products. Milan is an agreement between some Avnu members on how to do things with AVB. It is not a formal standard like AVB itself, but set of rules that they have decided upon for how to use the AVB standard within Pro AV.


Some more detail

Existing AVB audio is not compliant with Milan. Milan by default is 32 bit whereas previous AVB audio implementations use 24 bits. It’s all new. I assume most of this will be achieved with firmware upgrades and I have no information whether any of the existing shipping AVB products can or can’t be upgraded to support Milan.

It did strike me as odd that the compulsory Milan profile is 32 bit and one of the options is 24 bit, given that the vast majority of all professional audio is 24 bit. I’m sure there are reasons for this decision. They may take the Dante approach and just add trailing 0’s to make 24 bit up to 32 bit, but then allow scope for improvement without changing anything.

Milan compliance becomes part of AVB certification for ProAV. They also state that they are working on ways to simplify certification, which has been a cause of complaint from some. Milan certification will start in 2019.
Milan also supports redundancy for AVB streams, just like Dante and RAVENNA and unlike AES67.

Remember that AES67 was designed to be very simple in order to be as compatible as possible, so it deliberately leaves out features, such as discovery and redundancy. There are a number of manufacturers implementing ‘raw’ AES67 into products and while this is may be easy and cheap, it’s worth reminding them that this comes with compromises, such as no redundancy or additional (manual) effort to establish connections between devices.


Control

Remember this discussion not is about control. Milan, Dante and RAVENNA are all protocols for transporting audio across a network. None of these standards allow for control or monitoring of devices remote devices. Dante and RAVENNA have a means for managing connections and monitoring streaming status, and I assume this is true of Milan.

If you want to control devices across a network then you might want to read up on AES70 (OCA) or Ember+.


The verdict

Having met with most of the Milan creators, I think, or at least I hope, they know this will not be the audio networking protocol to take over the world.

Milan offers AVB features that frankly should have been there in the first place. It's a welcome addition to help AVB offer a robust, high-performance local audio network.

As with any new announcement we also accept that several elements are still incomplete – details on discovery, media clocking, redundancy and certification are still to come.


Switches

You still require AVB compliant switches. Whilst Cisco finally has some certified models, AVB switches are still rare and generally more expensive. There are some complexities and limits depending on what switch you choose (see the Biamp switch advice to get an idea about this). The majority of AVB switches require configuration, despite what Avnu say (here, here and here for example).

My position has been clear on this. Until there is significant adoption of AVB switches by the IT industry then we are wasting our time. AV professionals often cannot dictate the switch to be used for a mixed-use network. If you choose to run a network purely for AV, then this mostly defeats the point of the benefits that AVB offers.


OSI layer

AVB is still Layer 2. This means you can only have relatively contained networks. On a large mixed-use site, the network will be Layer 3. You can implement AVB systems within that large network, but only over portions of it. Your AVB connectivity will be limited to islands.


Industry compatibility

AVB is based on a completely different technology to Dante, RAVENNA, Livewire+, Gibraltar, Wheatnet and Q-Lan which are all AES67-compliant. AVB and Milan never can be AES67-compliant.


Open source

Milan is open source and manufacturers are asked to write their own Milan patching software, either as an application or within their products. This will likely mean you have to do more work than if you implement Dante or RAVENNA where tools already exist.

Milan has been created by a small group of manufacturers and they welcome others to join this collaborative effort but it’s not clear how requests for changes may be accepted by the originators of Milan. The open source nature of the project allows for forks or variants to be created – this can be seen as a benefit or a risk.

This is slightly different to Merging’s approach with ANEMAN. This technology was initially created to allow RAVENNA and AES67 streams to be patched. Like Milan, it is also a collaborative effort but under a ‘benevolent dictatorship’, ensuring consistency. Furthermore, there will shortly be an enterprise version of ANEMAN, intended to provide a revenue stream for its development and support.

When it comes to writing connection management software there is a lesson from Audinate. My understanding is that Dante Controller was initially written as a stop gap to provide patching for Dante streams and they soon expected manufacturers to write their own. Very few have. It’s difficult and expensive to write and support software, let alone get people to pay for it.

Avnu need to define a method of providing support for any Milan software. Open Source is great because it is free, but it means you have no comeback if it doesn’t work or doesn’t get updated. Personally I think the industry will be a better place when we pay for most of our software.


Summary

This realignment for Avnu is welcome and gives them focus and a direction to travel in.

However, it’s taken Avnu ten years to reach 28 shipping AVB certified ProAV products from six manufacturers. To put this in perspective, our industry has just surpassed 2,000 shipping networked audio products from 270 manufacturers.

Whilst the companies involved with Milan are mostly manufactures of ‘premium’ products, this is still a small project for them and the free nature of AVB and the writing of code to support and improve Milan means that resources may be limited.

Compare this to the 50+ engineers employed by Audinate, or the five businesses providing RAVENNA hardware and three providing software. It will be a huge struggle to keep up with those competing engineering efforts that, with AES67, also have the benefit of a degree of compatibility with each other.

With the AIMS alliance, ensuring that AES67 is the audio part of the SMPTE ST2110 video over IP standard, and Audinate joining SDVoE, perhaps offering some possibilities on audio to those members, Avnu’s sparseness when it comes to video is ironic for an initiative that contains the word, and when its alternatives seem to be making efforts in that area.

For small contained AVB implementations, Milan is definitely a good step, but they have a mountain to climb if they think that this can become the de-facto standard for audio or video within the ProAV market.

The landscape for networked audio and video is a changing one. The next few years are still uncertain. But there is already a lot of compatibility with nearly 700 AES67-compliant products. If you are not compatible with Dante, RAVENNA or AES67 then you are missing out on a lot of sales.

My recommendation to the Milan team is to review AVB switch adoption over the next ten years, after which AVB may have caught on in the IT industry. Will we be finally living in an IPv6 world by then, complete with all the changes that this may bring? For now, they should divert to using an existing AES67-compliant protocol and reap the financial benefit from compatibility with others. If they want a collaborative project, they can devote efforts to improving control, video or software in general – all areas that would benefit from the intelligence and ideas that the Milan promoters have.

It’s not that Milan is too little too late, just that it does nothing to make AVB solutions relevant to the vast majority of ProAV projects. But perhaps that isn’t their priority?

info@rhconsulting.eu