The Circle of HOPE (Hackers on Planet Earth) Conference Wrapup

Chelsea Manning speaking at the 2018 Circle of HOPE Conference

This was my eighth Hackers on Planet Earth (HOPE) Conference; I've presented talks at four conferences, and have assisted the A/V and Lighting teams in various ways over many years (writeups of past conferences and talks here). These remarkable, volunteer-run conferences, held every two years, feature knowledge, sharing, beauty, joy, community, and--always--a dose of chaos. The conferences are always inspiring, and--this year's alt-right trolls aside--I think this was the best HOPE yet, although you wouldn't know that if you only read about the conference on Twitter.

I was there all three days of the conference, went to probably a dozen talks in all three rooms, walked around the exhibits area, talked to many former and current students running the A/V, and other friends who are involved in running the conference. And I wouldn't have even known the level of controversy if I wasn't also active on twitter. What happened? Some alt-right trolls came in and disrupted the conference and intimidated a few attendees. None of that is good, of course, and the volunteer HOPE staff could have dealt with the situation better.  But I agree with the core idea of the conference organizers in that the answer to hate speech is more speech--not banning the wearing of certain hats (or people wearing them) as some people are demanding on twitter. 

Here's a pretty good summary of the situation, a support of HOPE and way forward by @JairusKhan on twitter (the whole thread starts here). Two important key phrases for me from Mr. Khan's thread was that after the incident "...HOPE should be considered under attack by [alt-right] agent provocateurs.", and ending with "But the reason why this all happened isn't because Nazis think #hopeconf is a safe space. It's because HOPE is where the people fighting Nazis are sharpening their swords.": 

 

I'm pretty much in agreement with Mr. Khan, and I don't have a lot to add, but I hope people will understand that this deplorable situation--intentionally caused by few people determined to disrupt-was a pretty small negative part of a conference that was otherwise overwhelmingly positive.

Of course one of the highlights of the conference for me was an inspiring talk from Chelsea Manning (photo above). She clearly, like many of us, was more comfortable as a geek in the shadows than as a public figure.  But she is now embracing her current role and bravely standing up to the many who hate and attack her. I was very inspired listening to her. 

I also enjoyed pretty much every talk I attended, all of which will be online soon (click on any photo to enlarge):

In the closing ceremonies (which I watched online yesterday since I was helping strike the other rooms while it was happening live), HOPE ringleader Emmanuel Goldstein, no stranger to controversy, seemed exhausted by the situation and afterwards even seemed to be questioning whether to even continue onwards.  I've long respected the way Emmanuel handles controversy; I think back to the way he and the HOPE core team handled a remarkable appearance in The Next HOPE in 2010 by Adrian Lamo, who had a major role in Chelsea (then Bradley) Manning going to prison (my writeup and photos of that appearance here). Lamo was widely hated by many at the conference, but in the Q&A part of the talk, Emmanuel, as moderator, demanded respect for Lamo while still allowing challenging questions to be asked.  This was remarkable and inspiring and to me represents the way forward.  Those who are currently attacking HOPE on twitter should keep this spirit in mind. Don't let the trolls divide us, let's rally around our community and overwhelm the hate with love and understanding. If trolls want to attend the conference and act respectfully, let them--they might even learn something. In this environment, we all need HOPE more than ever.

JH-20180722-IMG_20180722_195350.jpg

Beckhoff-Based Network Input Boxes for the Gravesend Inn

We've been doing the Gravesend Inn haunted hotel since 1999, which means 2018 is our 20th year! Some years ago, I started a quest to get all the control systems for the entire attraction onto a network, and I completed that in 2011 (more here). And as the attraction has grown in popularity (we have been getting nearly 5000 attendees a year for the last few), in recent years I've been on a new mission to streamline, simplify and completely document all the control systems to maximize reliability (and so that I don't have to be in the building to babysit the systems every minute that the show is open). Last year, I moved all the video playback to Brightsign players, and that really went great (you can read about it here).  

One of the oldest systems we currently use are our "TCP I/O" boxes, which date back to 2004, and are based on Advantech ADAM 6050 Ethernet I/O units. These units are cheap and, after I navigated a documentation nightmare, the units we built have been working well for 13 years now, with only a couple units failing over that time. But in the last couple years, we've had a few intermittent problems, where the box wouldn't boot up properly or other similar issues.  So, I've been figuring to move onto a new system, and given our educational mission, I wanted to go with what was most widely used in our industry, and these days it seems to me that the most widely used I/O systems are based on Beckhoff technology.  The big theme parks use a ton of Beckhoff stuff, as do other major players like Tait, Hudson, etc etc.  In addition, our original boxes were 12VDC, which worked well with the initial alarm grade motion detectors we used, but my survey of the industry showed that 24VDC is much more commonly used. With all that in mind, four years ago, as funding allowed, I started purchasing some Beckhoff parts, and worked with students through the years, culminating in the completion of three boxes this past spring.  On the summer break I finally got a couple days to finish configuring and documenting the boxes, and as usual, before I put anything into the Gravesend Inn haunted house attraction, I stress test is for typically several days or a week--I want to find any problems now and not in October.

For the system, I worked with Brian Buck, our Beckhoff salesman and selected a BK9050 bus coupler, which connects the I/O bus to the Ethernet network and speaks MODBUS TCP; and a KL1809 "HD Bus Terminal", which has 16 channels of 24VDC digital input.

This Beckhoff system is reasonably priced (by industrial standards) and very flexible. A wide range of I/O is available and can be mixed in the same system; Beckhoff is also very aware of our market and even has a section on their website for stage and show applications

Many years ago, in our I/O systems, we used XLR cables.  But at the time we had a limited stock of XLR, so I eventually moved to Cat 5 for sensor connections when we built our TCP I/O boxes. I chose Cat 5 because it is cheap and could easily carry these small currents over the distances we need.

This worked fine, but inevitably confused the students (students often think that a cable dictates what is carried over it (rather than the other way around), so they often think that the simple contact-closure based sensors we use were speaking Ethernet), and this led to patching problems. Fortunately, since Ethernet is transformer isolated, the systems wouldn't be damaged if incorrectly patched, but it still lead to confusion. So, moving to the new I/O system also gave us an opportunity to change connectors.  After a lot of thought and research, we decided to go with "M12" connectors, which are commonly found on industrial sensors. 

These aren't used for show purposes so cross patching won't be a problem; also they are very robust once connected.  Most factory automation systems, in which these sensors are typically used, are not set up and struck every year, so key to us being able to use this approach was finding field-terminatable connectors like these so we can make extension cables. 

Setting IP Addresses

Beckhoff has a very clever method to change IP addresses using ARP commands (see my book for more information about ARP and associated network topics).  To start this process, you first factory reset the bus coupler by powering off, turning all the DIP switches on and removing any I/O and terminating only with the KL9010 end block:

You then power off the unit again, connect your I/O, turn all the DIP switches off and power up again; this resets the bus coupler to its default IP address of 172.16.17.0.

To change the IP using the ARP method, you first run arp -a command to find out the MAC address of the unit, then you delete the entry, then you create a new entry, and then you do a special ping command to set the address. 

The manual in section 4.4.3 says, "It is, however, only possible to alter addresses within the same network class"; I assume the reason for this is in the final ping command you have to ping outside your subnet, and that won't be possible without a router.  But I figured out that if you have a computer with two ethernet jacks you can set one to a class B address and another to class C, and then connect cables from both interfaces to a switch connected to the Beckhoff (Note: I assume this would also work if you changed the IP address of your machine mid configuration, but I didn't try this).

Update July 9: Jim Janninck learned me on the fact that you can assign multiple IP addresses to the same interface!  Very cool. Use the "Advanced" button on the IPV4 interface screen.

It will show up in IP Config thusly:

Here's a log of the commands which are detailed in the Beckhoff manual (replace your desired target IP with the 192.168.1.xxx address, some MAC and other addressed munged for security reasons)

First, let's run IPCONFIG to check the two IP addresses I configured into my PC:

C:\Windows\System32>ipconfig

Ethernet adapter LAN 2 PCI:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.1.123
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter LAN 1 Integrated:

   Connection-specific DNS Suffix  . : 
   IPv4 Address. . . . . . . . . . . : 172.16.17.123
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Now let's ping the newly factory reset bus coupler to get it in the ARP table:

C:\Windows\System32>ping 172.16.17.0

Pinging 172.16.17.0 with 32 bytes of data:
Reply from 172.16.17.0: bytes=32 time=3ms TTL=60 ...

Now let's run arp-a to get the MAC address of the bus coupler:
C:\Windows\System32>arp -a

Interface: 172.16.17.123 --- 0xb
  Internet Address      Physical Address      Type
  172.16.17.0           00-01-05-xx-xx-xx     dynamic

Interface: 192.168.111.123 --- 0xd
  Internet Address      Physical Address      Type

Now, let's delete the ARP table entry for the bus coupler:

C:\Windows\System32>arp -d 172.16.17.0

Now let's create a new ARP table entry

C:\Windows\System32>arp -s 192.168.1.xxx 00-01-05-xx-xx-xx

Let's check to make sure it's there (note that it associated with the 192.168 interface):

C:\Windows\System32>arp -a

Interface: 172.16.17.123 --- 0xb
  Internet Address      Physical Address      Type

 

Interface: 192.168.111.123 --- 0xd
  Internet Address      Physical Address      Type
  192.168.1.xxx        00-01-05-xx-xx-xx     static

Now let's run the special PING command that sets the address.  This is where you need the second interface (or you need to change your IP address to something in the new subnet range before you try this):

C:\Windows\System32>ping -l 123 192.168.1.xxx

Pinging 192.168.1.xxx with 123 bytes of data:
Reply from 192.168.1.xxx: bytes=123 time=622ms TTL=60
Reply from 192.168.1.xxx: bytes=123 time=2ms TTL=60

 

Now let's run ARP -a to check to make sure everything came through OK
C:\Windows\System32>arp -a

Interface: 172.16.17.123 --- 0xb
  Internet Address      Physical Address      Type

Interface: 192.168.111.123 --- 0xd
  Internet Address      Physical Address      Type

  192.168.1.xxx           00-01-05-xx-xx-xx     dynamic

And that's it!

BootP Server

An alternative to the ARP based method is the BootP Method , where a BootP server is used to assign addresses based on MAC addresses.  To allow the BootP method, you turn DIP switches 1-8 and 9 on (10 off) and once you configure the address, if you leave the DIP switches in this setting, “The address assigned by the BootP server is stored, and the BootP service will not be restarted after the next cold start. The address can be cleared again by reactivating the manufacturers' settings ...“ Beckhoff supplies a BootP server called “TCBootP Server”

Watchdog Timer

These Beckhoff modules have a watchdog timer for enhanced safety on outputs.  From Page 53 of the manual:  

The watchdog is active under the factory settings. After the first write telegram the watchdog timer is initiated, and is triggered each time a telegram is received from this device. Other devices have no effect on the watchdog. ...  The watchdog can be deactivated by writing a zero to offset 0x1120. The watchdog register can only be written if the watchdog is not active. The data in this register is retained.

Note it says the watchdog timer is activated by the first write "telegram" (MODBUS TCP write Coil or similar) so if you only ever do read operations (what we do for inputs on these boxes) the watchdog timer will never be started. Once the timer is started by a write command, if no MODBUS TCP command (read or write) is received within the timeout (typically 1 second) the unit will go into a fault state (red watchdog error LED will light) and the outputs will shut off.  You then have to go through a reset procedure to activate the unit again.

To disable the watchdog timer, you have to (as detailed above) write a zero to offset 0x1120.  Through experimentation I found that you have to do this before any write (output) commands are issued, but only after the unit has completely booted up. Watch for the activity LED on the Ethernet port to light up before issuing the command.

Note: If you trigger the watchdog timer (red light on), then issue a reset, and then write the timer to 0, then the unit will function with no watchdog functionality but the red Watchdog error light will remain red.

Connecting to Barco Medialon Manager  

The Gravesend Inn has been run by Barco/Medialon Manager show control software since 2002, and the way I always incorporate any new technology into the network is to first write a small, stand alone Manager program for the new device only, test that, and then import it into the larger Gravesend Inn program. Since this box is input only, and we are not doing any write operations, we disregard the watchdog timer. In Manager you have to configure both the I/O resource and a device pulling from that resource. 

You then assign the resources to a Medialon I/O device:

IOConfig.PNG

Reading and Writing

Note: The Register Numbers in Medialon are "off by one", meaning they are one higher than the Register Numbers in the Beckhoff. For example, Register 4385 (0x1121) in Medialon addresses Register 4384 (0x1120) in the Beckhoff.

Reading Inputs

The inputs on the device are read automatically by the I/O resource if configured as shown above.

Writing Outputs

We're not using this (and if you do, you have to manage the watchdog stuff) but for posterity here's the information: outputs are written using a “Write Coil” command starting at address 1

I ended up with a simple little polling program:

The boxes are undergoing stress testing now, and if we get funding to replace our cables, I plan to start transitioning the Gravesend Inn sensor systems over this year to the new boxes.

Several excellent students (many now alumni) worked with me on this project over the last four years. Michael Sauder, now at Radio City, did the initial testing on and configuration of the Beckhoff units from Medialon manager. Tim Durland, now at Smart Monkeys, expanded on Michael's work and figured out the watchdog timer issues. Woody Woytovich, now in his Local 1 IATSE internship, did the box layout and schematic and constructed the first one. Dominique Hunter, Bailin He, Neil Carman, and Daniel Santamaria all worked on constructing and wiring the last two boxes this spring. Thanks as always to Eric Cantrell of Barco/Medialon for helping us with protocol details on this project and Jim Janninck of Timberspring for advice on box construction and initial testing.

Note: Updated July 9, 2018 with updated ARP-based IP and Medialon Configuration; thanks to Eric and Jim for the updated info.

Audinate's Dante (and SDVOE?), AVB/TSN and AES67: An Audio Networking Update After Infocomm 2018

It's become an annual tradition-since 2009 I've been writing about networking from a live sound perspective after catching up from Infocomm (and this year after storm chasing). You can see last year's entry here, and in this overly jargon-filled post I'm assuming you're familiar with the A/V networking landscape; if not, much of the terminology I use here was defined in previous write ups.

This year, I would describe the state of the A/V networking world to be pretty much the same as last year, with some interesting developments on the horizon. The lion's share of the products on at the show running audio over ethernet are doing so with Audinate's Dante; a few (important) companies are running AVB. 

Update July 6, 2018: Roland Hemming's annual audio networking survey data has been released, it's an interesting read and supports my anecdotal observations above.

Audinate's Dante

I unfortunately missed the Audinate networking world day-long event this year, so I might have missed some new products. But seeing new Dante product at Infocomm is such a common occurrence now that I didn't even really bother to try and document it. The AVNU (AVB/TSN) alliance did not have a booth as far as I know, but Audinate was there with a Dante booth and there were numerous "Dante spoken here" signs throughout the hall.

One of the trends I saw is that there are now quite a few small Dante I/O boxes on the market now, including the original ones from Amphenol, from Audinate itself and also NeutrikAll these smaller boxes that I've seen only deal with line input and don't have head amp control or phantom power, so if you want to use a mic input you need something like a Yamaha Rio. Yamaha showed their new V2 series of boxes but I completely forgot to get over there to look.  To control the head amp/phantom on these you still need to use a modern Yamaha console or their R Remote software.  Update 12:11pm: See comment from Uwe Weissbach below--apparently the new Rio's can be controlled from the front panel, which I think is great.  

One cool new Dante product I saw was a USB DANTE Interface from RME that supports redundant Dante operation. This is a great a benefit over the Audinate Virtual Sound Card, and also offers more flexible clock options (I'll be looking into these for our haunted house to increase our redundancy). They also are making an AVB interface.

 

 

 

AVB/TSN

Cisco's Catalyst AVB switches were announced in 2016 (see my writeup here) and are now finally AVNU certified (and Cisco has a section on their website devoted to AVB). This is a long overdue development for AVB in large installations where the users can have the IT support to manage these high-level switches. Personally, though, for most typical live sound applications I recommend simpler switches; I personally use the Cisco small-business switches and that's also what Yamaha typically recommends. I asked the Cisco rep if AVB was coming to that line of switches but he didn't know.

Presonus also had an AVB switch on display, but, like the MOTU AVB switch which came out a few years ago, it's not AVNU certified. The Presonus sales rep on the stand didn't know what AVNU certification was (here's a writeup and photos of my visit to the AVNU Testing lab in 2013), so it doesn't seem to be a priority for them and they don't have any products on the certification website in any case. In 2015, a rep from MOTU said on the theatre sound mailing list in response to a thread I started, "AVnu certification is a priority for us but our interfaces and switch are not certified nor have we applied for certification yet. There were a couple of corner-case AVB features that kept us from starting that process when we released our first AVB interfaces last year. Once those are ironed out and solid, we plan to get certified."  That was three years ago, and they are still not listed on the AVNU site, so it seems that certification is no longer a priority for MOTU either. So what's the value of the certification, if these well known companies are out there selling AVB product that is not certified? Since last year's Infocomm, in addition to the Cisco switch, there's only four new products on the AVNU certification list: the L-Acoustics LA4X amp/controller and P1 Measurement Platform/AVB Processor; and the Control4 S3-24P PoE switch, which describes itself as a "leader in the smart home market" (and I don't think they were at Infocomm as far as I could tell). 

Connecting Dante and AVB and AES67

There seemed to be more connecting and interfacing boxes available, and AES67 functionality was advertised all over the floor (and I'm still looking for some non-Dante stuff that speaks AES67 so I can learn it--please contact me if you have any gear I could borrow!). Point Source Audio had this on their stand, the AuviTran AVBx3 Audio Toolbox, with both AVB and Dante card. Presonus was rumored to have a similar product, but the sales rep there said it wasn't ready in time for the show.

 

 

To Watch For the Future: AVB/TSN and Milan

The biggest A/V networking news at Infocomm was the announcement of "Milan", a new effort to help with AVB inter-operability. They had a roll out at Infocomm, but I was not invited--I only found out about it at all because I was hanging out talking to friends on the d&b stand. My friend and audio networking expert Roland Hemming, who I missed at Infocomm, did make it into the meeting and has written his insights which you should read here. "It was a nice presentation from the Avnu team", he said in his write up, "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."  This is kind of the tone I too felt reading through the AVNU Milan web page here, and the whitepaper which you can download here if you register.

What is Milan?

The AVNU Milan website describes it this way:

AVB is an open standard that each manufacturer can use in their own implementation, but device interoperability isn’t guaranteed without certification. Avnu Alliance compliance testing and certification is ideal for network infrastructure switches and ensures interoperability at the network layer, but doesn’t outline specification requirements for the application layer such as media formats, media clocking, and etc. It doesn’t assure interoperability amongst Pro AV end devices. Milan does.

Effective inter-operability was a goal of AVB from the beginning. The first thing I wrote on AVB in 2009 had a quote from a (now gone) roll-out article written by one of the key developers of AVB saying a key goal of the effort was to, "...enable the construction of highly interoperable Ethernet networks capable of streaming audio and video with perfect QoS." So the very existence of this Milan effort for me points up the shortcomings of AVB, and one of the reasons I think AVB hasn't gained broader acceptance: nothing in the existing standard offers the user anything like the plug and play patching convenience we already have today with Dante (of course I've written a lot about that already). Even in Milan, from what I understand, the way the patching will done--which is what the users actually interact with--is still left up to individual manufacturers (or maybe a third party?) to handle. For competitive reasons there's not really much incentive for clean, unified plug and play multi-manufacturer signal routing that is consistent for the user, and I doubt it will happen any time soon in AVB systems, if ever.

What Will Milan Offer?

In the section titled benefits for "AV System End Users" (who are listed fourth after Manufacturers, AV Managers, and IT Managers), the Milan white paper gives us the following:

* Milan fulfills expectations for real plug-and-play net-work setup and functionality. Network structures don’t require setup or complicated switch configuration tasks.
* Networks as signal and control transport structures becomes easy, fast to set up and reliable. Users can concentrate on their creative tasks.

Neither of these things is true today in AVB systems, where real, practical multi-manufacturer inter-operability exists only in limited ways. But every time I fire up Dante Controller I'm always impressed at how fast it discovers everything in a truly plug and play way. Most Dante networks require little or no switch configuration, and I would say already allows users to concentrate on their creative tasks. 

The whitepaper goes on to lay out a list of promises, and while the word "Dante" doesn't appear in the document it's clearly targeted at some perceived version of the Dante world, with references to not depending on a "single company", etc. And there some inferences in the paper that, if interpreted as veiled references to Dante, are not accurate (like they imply that you need to configure switches and QoS for Dante, which you only have to worry about for the largest of systems (think airport size systems). 

In terms of technical details, the white paper offers the following four things:

  • Media Clocking Specification
  • Stream Format Specification
  • Redundancy Specification
  • AVDECC Specification for Endpoints

This is pretty low level, basic stuff; Roland has more detail in his writeup. And of course none of this changes the fact that to run AVB you still need to buy AVB-capable switches (certified or not). In terms of actual benefits for the user, the most interesting thing is the AVDECC implementation (which I had to look up).  Regarding this, the whitepaper says, "... Milan defines a profile for professional audio devices with a small subset of the standard, and tries to remove all ambiguities from this subset in order to achieve basic inter-operability at the Control layer." 

"Control" of the discovered devices is promised, and, being the controlgeek blog, this is something that caught my eye. As we've seen many times, real, multi-manufacturer control that is successful in the market is something that is rare in a competitive industry, and I've documented this in my book since the 1990s and here on the blog (I have examples under the heading "limitations of standards" extracted here).  But specifically for the audio market, we can look back to the development in the late 1990s of AES24 and its eventual market failure and withdrawal in 2004. AES24's legacy lives on in OCA/AES70, but for similar reasons that's only achieved limited success in the market, as I've detailed starting in 2012.  Again, OCA and AES24 were developed by very smart and capable people (and friends of mine), but market adoption has been limited for the usual competitive reasons: many audio manufacturers put EQ in their products, but it's very difficult to get them all to agree as to how that EQ should be controlled. And it was amplifier manufacturers, back in the days where you would buy them separately from speakers, who all offered incompatible, non interoperable control solutions and did not support the initial standardization effort. Sound like a familiar situation?  Easy exchanging of digital audio streams, on the other hand, is something that's in everyone's interest. (And ironically, Audinate is actually in a position where it could dictate some basic control functionality, like at least head amp gain and phantom power status).

Who Developed Milan and Why? 

This part of the whitepaper really felt condescending to me, and seems to have been written by a bunch of very smart people who haven't really done their market research to see what people are actually doing today in the field (or the text was fluffed up by a very competitive marketing person):

Milan is the result of 18 months of close collaboration amongst direct competitors including AudioScience, Avid, Biamp, d&b audiotechnik, L-Acoustics, Luminex and Meyer Sound. Milan was created by the technical experts designing the systems and driving product roadmaps to impress upon other manufacturers the importance of this technical transition for the future of their business. 
Market leaders decided long ago that AVB is a technically superior network technology that guarantees deterministic delivery of audio, video and data, and offers a sustainable standard technology that is not limited by one company’s vision and its future development and support decisions for its technology.
...
Today, major manufacturers in the Pro AV space have taken the lead with the first tangible solution to promise deterministic, reliable and future-proof delivery of networked media.
...
The Milan initiative is a long-term approach to bringing about change across the Pro Av market, and product certification will guarantee fool-proof interoperability of deterministic networked Pro AV devices.

This all seems to reflect the viewpoint of many of my manufacturer friends who are not on the Dante bandwagon. They understandably don't want to base their products around a core technology from another company (Audinate), and many of them seem to think that Audinate will eventually get bought up and could stop development of Dante (which is what happened to Cobranet), or go in another direction or something. And they think AVB will be there waiting to take over. These are a lot of brilliant people but I think they are wrong. 

Where Will it Go?

At my school, we bought a Yamaha CL-5 mixing console. I picked that board because it's widely used in the NYC event market, many of our graduates will encounter them in the field, they are well made and affordable. Given the reality of budgets, we will likely be using this console for the next 10-15 years. That means we're running Dante for the next 10-15 years, even if Yamaha and Audinate both went out of business. And many rental shops around here and touring sound companies are in the same boat. And with so much Dante product in the world (and the rumor that Yamaha owns a stake in Audinate) if Dante development stopped, it's likely a consortium of manufacturers would continue it anyway.

But in the end this Milan effort seems to be led primarily a group of high-end loudspeaker manufacturers (all of which I'm a fan of), and I'm not really sure how--other than guaranteeing that there will be a group to continue some kind of development--Milan will really benefit users. If you're buying d&b speakers, you're going to have to buy a d&b controller/amp anyway. If you're running all self-powered Meyer speakers, you could use anyone's speaker controller but why would you when Meyer makes such great controllers already optimized for their systems that's integrated with their modelling software?  And L'Acoustics has been moving in recent years towards their multichannel, control-intensive L-ISA system, which is dependent on their own DSP. So while I applaud and wish well any sort of forward movement towards any sort of inter-operability, and I hope Milan succeeds, I don't think it's the game changer they seem to be advertising.

And I don't think I'm alone in thinking this way. I was emailing with a friend who works on major Broadway productions about this new effort, and he already knew about it and said, "It seems to me, as an end-user, unless you can get DiGiCo, Yamaha, Studer, and the console big-boys on board, any discussion of audio transport is missing a crucial component. If they can get DiGiCo to come out with a Milan card, that could be cool."  But that wouldn't mean he no longer needs Dante.  "Right now, DMI-Dante [interface cards are] how we interface with our audio networks, and it works seamlessly at the other endpoints (speakers, monitoring, other consoles, computers, and remotes)."

And Roland Hemming summarized thusly, "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."  

Two Networks for the Future

It seems to me (again, in the live sound world) we will remain for the foreseeable future a two-network world (plus MADI, etc of course), and while this is not ideal, that's the way these things always seem to work out. On many systems, Dante will connect the console, microphones, stage boxes, wireless mic receivers, recording rigs, in-ear monitors, measurement systems and associated gear and often the loudspeakers, with companies like Martin offering direct Dante to their boxes. But if the speaker system is Meyer, d&b or L'Acoustics, then these systems will be running AVB, probably on a completely separate network with separate AVB switches, and the two networks will be connected with some kind of rudimentary, small channel-count interface, a converter box, or--if we're really lucky--AES67 based network interchange. 

But while Audinate has embraced AES67 and incorporated it into Dante, companies like Meyer have not embraced AES67 and don't seem to have any interest in doing so. I talked to my friends at Meyer about a huge and very cool AVB-based system they built for Metallica, and asked them how they got audio into their speaker system from the console. The answer?  AES3, the two-channel point to point digital audio over XLR connector standard first developed in 1985. This is better than analog, of course, but we should be doing better than that in the 21st century. But in reality, this is an OK (but limiting for the future) solution, since in a concert system typically only a handful of the many channels of the overall system are sent over from the mixer to the speaker system, and this console/speaker system dividing line also reflects a common division of labor anyway, with the (human) mixer responsible for most of the stuff up to the console outputs and then the system tech handling the speaker systems and alignment.  This is good enough.

And, as I've written for many years, "good enough" is where technology typically settles, until there is a compelling reason to move forward.  Milan, at least as currently outlined, is a useful, incremental, and overdue improvement to AVB, but not compelling (or complete) enough to replace Dante in the market any time soon--certainly not within the time horizon of someone who has to buy or spec a system today.  For the future, who knows, but of course, Audinate is not sitting still:

SDVOE Over Dante?

The world of video over Ethernet is still a bit like the wild west. One really interesting proof of concept on the show floor was Software Defined Video Over Ethernet (SDVOE) implemented by Audinate into Dante. They were doing presentations and had a working proof of concept system; I saw it patch video right through Dante controller, which is very cool.

At least for an end user like me, seeing things like this operate is when it really seems real to me. We've been seeing SDVOE development boards and so on for years, but when you see Dante controller patch video, even in prototype form, then it seems like a real thing.  We'll see what comes in the next year.

More photos from Infocomm here.