Ethernet Switches

[Dave Macaulay]

"What do you consider to be "Atmos" in terms of transmission protocols?"
This is the Atmos audio object data from server to CP950A. The processor will get it on the management network if there's no path to the 1710 input.
The CP850 digital audio output as AES67 or BluLink, to the best of my knowledge, has to be on a separate network segment. Using Dolby DMA amp(s) or Dolby DAC(s) ... it just works.
We've been using JBL DSi-D amps, and that has been a learning experience. Yes it works but there have been some issues. The AES clock is a problem, the Dolby really doesn't work as lead clock. Assigning one of the amps as primary leader and setting the 950A to never be it has worked. Otherwise amps drop out and sometimes are permanently locked out. I haven't found out what the real issue is, this is a workaround that has been stable. The amps have an Audinate Dante subsystem that can presumably do full on Dante, for Dolby AES67 the Dante higher level capability is missing and just the audio streams are used.
I heard that JBL/Crown told Dolby they wanted to do digital audio to the amps, Dolby said "that won't work", and JBL/Crown showed them a system with it working. Support from Dolby for this approach is still not great. They want to sell DMA amps, I guess, but although great for some systems DMAs have troubling limitations.

[Steve Guttag]

I think there is a slight confusion or conflating of the "Atmos Audio" There is the raw data that is coming from the server. That is the pre-rendered data that can run on a conventional network so long as there are no underflows. This is what can run into a CP950A's "Control Network" NIC and why the CP950A has to have a KDM as well as the server. The CAT1710 is a mediablock just like an IMB. It is taking encrypted content, via network, and turning into audio (albeit, with watermarking).

The AES67 audio that is coming out of a Dolby Atmos decoder (regardless of model) does not, technically, have to be on its own network or segment, beyond I'm sure that Dolby would require the two NICs not be on the same subnet. One could set up a switch with proper QOS and VLANs to allow a successful streaming transmission, you are having to do backflips to do it unless you really segment off your switch into separate VLANs. In my typical Q-SYS system, particularly with Atmos, I have enough devices on the QLAN that you'd want a separate switch anyway (a separate NIC for each 4 or 8 channel amplifier with 50-60 channels being typical). The easy button is a separate switch and LAN as it solves numerous potential issues with streaming audio and multicast traffic.

I have not had any issue with Dolby being the PTP GM clock (nowadays called the Clock Leader). Q-SYS will clock off of it well enough. The big downside is that is creates multiple LANs as each Atmos processor wants to be the clock leader. If they could clock off of another (RELIABLY being the key word here), then you could have either Q-SYS, in my case, or a standalone PTP clock work for the entire complex.

[Harold Hallikainen]

I continue to hear issues with network flooding. I have not seen WireShark captures of the issue recently, but previously I did see packets that I somehow figured out were Atmos (It's been a while). In that case, captioning died every night at 7pm when another auditorium started playing an Atmos movie. As discussed previously, the fetching of the content by a CP950 or similar from the server results in a lot of data going from the server to the CP950. But, I believe this should be unicast (HTTP), so it should not "escape" the auditorium. The output of the CP950 could be multicast AES67. I THINK this should be on a totally separate network, but apparently it is ending up on the control network and switches are converting the multicast to broadcast and hitting our device which currently has a 10 Mbps Ethernet interface. If you shove network audio at that, many packets get dropped, including packets that were supposed to come to us. A possibility is upping the network interface chip to 100 Mbps, which should reduce the issue, but it still seems like we could suffer massive packet loss due to network flooding.

So, is this a misconfigured or miswired network, or do I need to try to put a Gbps Ethernet chip in a device that needs a few kbps?

[Marcel Birgelen]

AES67 uses multicast. If your switch doesn't do IGMP snooping, multicast will be interpreted as broadcast and will therefore be distributed to ALL ports on that switch. Broadcast traffic is expensive, also for end-devices, as they need to listen to every single packet in order to see if it's addressed to them or not. Hence, every broadcast packet will be processed by the kernel of the OS running on the device you're broadcasting to. I'm pretty sure you'll completely kill a device like a CP650 with 10 MBit of broadcast traffic.

If auditoriums share the same "broadcast domain", e.g. aren't isolated in separate VLANs, or if VLANs end up being wrongfully bridged, the multicast traffic of one auditorium can end up in another auditorium. I don't think your solution is to upgrade devices to gigabit, your solution is in stopping the leakage.

[Steve Guttag]

Dolby doesn't help the cause with their casual disregard for AES67 protocols and how they advise network setup. If you hook up a Dolby only system with an unmanaged switch in a laboratory situation, then it all works. If you use IGMP snooping with Dolby equipment, you'll lose AES67 as it won't respond to the query (depending on the equipment and firmware...the IMS3000 being a big offender from 3.5 onwards).

GDC can hurt your cause too. They only put two NICs on their SR1000. So, one of those is going to have to be transmitting the raw Atmos data. Which network do you want, the Control or the Media network? Dolby make the Control Network the choice. So yes, they are streaming the data from the server to the CP950A on the control network. It should be unicast though. I do not know the bandwidth. However, that should only affect that local theatre.

AES67 should only come into play on the output of the IMS3000 or CP950A. That should NOT be on the control network (or media network). If it is, then that is a bad network design, in my opinion It is absolutely multicast and without proper network configuration will flood everything it touches. Depending on the equipment, you could get away with a "cheap" switch. For instance, if you use all Dolby products...amps, DACs then even an unmanaged switch will work with 1G ports. However, that presumes it is an isolated network JUST for that one theatre's AES67 traffic.

I have numerous sites with Dolby Atmos, UPC28c and I am not having flooding or conflict issues. If you desire, in the Q-SYS Corner thread, I just recently posted blog-25 that details how I do it. In short, I use one network (QLAN-B) for redundant AES67 traffic and control in my Atmos systems (using small Q-SYS Cores with just 2 NICs). They are on managed switches to deal with AES67 and multicast. I then send control information via a router (and that is where multicast ends) to reach the control network (and vice-versa). So, between the router and even the managed switch, IGMP snooping ensures that the control network never has to put up with the multicast streaming of an Atmos (or any other Q-SYS) audio.

[Jay Wyatt]

Harold,

I'd first determine if the "atmos" packets are either:
1) Raw metadata going from IMB to Cinema processor. I believe these will show up in wireshark as TLS, TCP, and HTTP packets. This is often put on the management/control network but sometimes is point to point from IMB to Cinema Processor -- depends on what IMB and how eth ports are allocated. This traffic is ultimately destined for the Dolby Atmos Input port on the cinema processor.

2) Post Renderer, Atmos AES67 streams. These would show in wireshark as multicast streams with an address of 239.X.X.X and can eat some significant bandwidth. These leave the Dolby Atmos Connect (out) port and this traffic is rarely found on Mgmt/Control networks -- normally a dedicated A/V network. Unless theres a very sophisticated network scheme and knowledgable IT admin I would advise against it converging MGMT and AV. If you see these packets on the same network as the IRC-28 then its very likely the network scheme for this site needs an overhaul or some TLC.

If 2) it's not surprising at all the multicast data is flooding a 10Mbps interface. I've even seen 100Mbps (QSC touchpanels) devices get crushed. The total bandwidth required for eight AES67 streams, each carrying eight channels of 24-bit audio at a 48 kHz sample rate with a 1 ms packet time, is 92.16 Mbps. So yes 64ch of multicast could easily saturate an IRC interface. Enabling IGMP Snooping at the switch level can solve this but also come with its own set of problems (as Steve mentioned). The easy answer is they should really have separate networks for audio and control/mgmt.

[Dave Macaulay]

We have several systems running with CP850/950 Atmos over AES67 to JBL DSi2-D amps. These include Dante boards from Audinate to handle the digital distribution.
Yes the Dolby implementation of AES67 is a bit less than perfect. And AES67 is not Dante, just its audio format. So some trickery is involved. From my understanding, Dolby just told Harmon/JBL that this could not work.
But they made it work. The processor and amps have some pretty specific setup options to use, and amp firmwares have to be up to date - the Audinate firmware is from Audio Architect not direct from Audinate so there may be some modifications to work with bare AES67.
I think we did the first live installation. Currently there are maybe 5-10 running.
The audio distribution can't be on the management network. I do not see any way that could work.
One client tried to use cloud managed switches with multiple VLANs but that didn't work. The advice we got from JBL was pretty much "don't try that".
We use a dedicated managed switch for the AES67 with one VLAN, IGMP snooping off. We have had issues with the clock, with weird muting and popping when we had used snooping (as initially suggested by JBL). Each system is independent.
I understand how Qsys works (up to a point) but worry about single failure points that would affect multiple screens. True Dante looks like it could do the same stuff but with that problem as well.
- The 950 does not want to be lead clock. Any amp can be set as lead clock and it works just fine.
- Audio Architect is a real PITA when working with one system, using maybe 0.5% of its capability. Filled with not too obvious options that have to be just right.
- PTPTrackhound is very useful for tracking down issues with the multicast system.

[Steve Guttag]

Dave,

I think you could combine the management an Atmos networks (I'm not recommending it). But you are going to need IGMP up and going. It is the only way I know to ensure that multicast stays where it belongs and doesn't flood everything. Again, I'm not recommending it. I think what would make it likely impossible in your application is the use of the CP850/CP950A...they are not going to want the Control and Atmos networks to be on the same subnets. It might let you get fancy by using the subnet mask to break up the LAN but how many hoops does one have to jump through to save a network? And where does that cost lie compared to just adding the switch and Atmos LAN?

The bring problem with IGMP is Dolby. Their products won't respond to the query so the snooping will shut multicast off from them...which kills the audio. Depending on the switch(es) you are using, you should be able to set the ports with Dolby things attached to be a static router port (essentially force multicast traffic on for those ports).

As to Q-SYS, in general, since I use IMS3000s, primarily, for my Atmos decoders, it isn't an option to have multiple screens use a single Q-SYS Core (they HAVE to be the clock leader). As such, I set up my Atmos AES67 domains separate on each Atmos screen. But let's say I'm using the CP950A. Single point of failures are not an issue with Q-SYS because you can double-up Cores for automatic redundancy. I do this with multiplexes all of the time for non-Atmos. If you think about it, it is even more resilient than a conventional system since EVERY screen is now backed up. What may pose a challenge with multiple Atmos systems would be the channel count and AES67 streams on a single Core (or redundant pair). Then again, a pair of Server Core X20r can support up to 384 channels (in and out). So, depending on the size of the complex and how many Atmos system to be supported, there are options. I've been content to let the smaller Cores, like the Nano handle my Atmos theatres. They can go up to 128 channels, which covers Atmos

[Jay Wyatt]

Emphasizing that its not best practice to converge AV and management but one could manually configure static multicast filtering to prevent flooding and avoid IGMP snooping altogether.

Example in Netgear CLI:
macfilter add <MAC_address> vlan <VLAN_ID> destination
macfilter add 01:00:5e:01:01:01 vlan 100 destination 1/0/5,1/0/6
This ensures frames for that mac only reach ports 1/0/5 and 1/0/6—no flooding to other ports.

*this would break if you were to move egress ports to amps (port index would move) or swap processors (pinned mac address would change).

[Harold Hallikainen]

Thanks for all the comments! I did a search of my computer for all pcap files. I found several, but not the one where I was seeing audio from another auditorium.