CP850/CP950A/IMS3000 AES67 Output

[Marcel Birgelen]

I personally have given up on IGMP and disable it on any VLAN where it might be used, simply to avoid potential headaches... The cross-device, cross-vendor compatibility simply isn't there and IGMP snooping gone wrong will lead to interesting and often hard to debug connectivity issues.

If you carefully segment your network into VLANs, then the additional broadcast traffic created by NOT having IGMP should also not be a problem. So, do not mix multiple AES67 connections on the same VLAN or rather use a separate VLAN for every AES67 link and keep your broadcast-heavy traffic away from "machine LANs", as broadcast traffic will cause a load on all devices involved. A broadcast heavy LAN might actually kill your ethernet connectivity (or worse) of older equipment like a CP-650.

[Steve Guttag]

Without IGMP, you run the risk of a CORE not finding/seeing peripherals like touchpanels or even amplifiers. My QLANs are separate LANs. I do, for the smaller COREs put control and the redundant network on the same LAN (QLAN-B). But, to get the booth LAN (where the automation, projectors, TMS...etc. reside), I have all controls go through a router. IGMP is blocked there so there is no chance of IGMP related issues. QLAN-A is as air gapped as I can get it (the service PC is on it for support so not air gapped but if there isn't a wire connected to the network, there is no other connectivity).

I don't use IGMP in other places

When other forums with QSYS report devices disappearing, 9 times out of 10, IGMP isn't configured. I've had zero incidents of that.

[Marcel Birgelen]

Interestingly, I've not yet really had similar issues yet with Q-Sys. But, with giving up on IGMP I mean trying to have switches play nice with IGMP snooping, not IGMP itself, which is largely out of my control anyway. Disabling IGMP snooping on your switch should not lead to connectivity issues, as multicast traffic will simply be seen as broadcast traffic. Once you enable IGMP snooping, a switch will listen to IGMP traffic and match that with the MAC address tables and will only send multicast IP traffic to those ports that contain active subscribers. When a switch misses or misinterprets such an IGMP packet, the result often is that the new subscriber will not be served the multicast traffic. Without IGMP snooping, all multicast traffic will end up on all the ports in the same "broadcast domain" or "(V)LAN" and it's up for the devices themselves to check wether or not it's relevant for them.

QDP, the Q-LAN Discovery Protocol uses Multicast, just like a bunch of other discovery protocols. If IGMP snooping on your switch is a mess or something is blocking IGMP traffic, it may not work correctly.

[Jesper Meng]

I can make subscriptions from IMS3000 and C950 to ULTIMO2 equipped Dante devices. I use RAV2SAP to make SDP.
I have a Netgear 4250 switch but it work with a simple switch as well

I have used many (Covid) hours trying to make working subscriptions to my Brooklyn equipped Dante products, no audio, clock is working, subscription fine. I have an amp with Ultimo chip and that works as well.

I do one offs and festivals, so i would like a setup with discrete AES3 channels and Dante. I do not have other Qsys products, but i know it would work.. :-)
I have tried the Merging Hapi, and it worked as well, but no Dante

[Steve Guttag]

I'd say "be careful" with the Dolby stuff. Particularly, if they are not the clocking source. They don't fully implement AES67 (hence you can't use IGMP snooping) and those that have tried to get them to sync to external PTP clocks have found that they seem to work...at first...but lose sync over time. There have been software revisions since the last test that I was aware of (including my own where I did have an IMS3000 clocking off of a QSYS CORE). I saw a lot of "Compromised" warnings the last time I tried though the audio appeared to be moving fine...clearly, some more fine-tuning was needed. The last incarnation of the DMA firmware seemed to really try to allow the DMA to work with AES67 from other devices. I've found it mostly reliable but have also found them to, on occasion, to drop a stream and if you toggle the stream, it will immediately acquire it again. Is that the fault of the transmitter or the DMA?

I don't have the warm and fuzzies enough to entrust them on a screen channel and until I can prove that switching the GM clock to the CORE (which would simplify my systems where QSYS is running an entire complex), Dolby remains an overhead to AES67 systems that has to be coddled. Dolby does not seem to want to invest resources in making their products robust with AES67 beyond connectivity to their own products. And note, if you are connecting IMS3000 or CP950/CP950A to a DMA...no need for managed switches because, in their mind, it is a closed system.

I do wish that they would embrace "Network Redundancy." They sort of did with their original Blue-link thing but with Atmos Connect...everything is depending on a single $1 patch cord and connector and 1 network switch...etc. There are a lot of single-point failures. With network redundancy, for almost no extra cost, you practically eliminate those sorts of failures. And, if the device can communicate that it is having a network issue, one can address a problem before you exhaust your redundancy.

[Harold Hallikainen]

I have not dug into network audio much, but the clock master seems like an interesting issue. When we were designing the JSD-60 and JSD-100, we put sample rate converters on all the AES3 inputs so the DSP in the JSD did not have to be synchronized with the AES3 from the digital cinema server. This made the audio "not transparent." On units where we had a digital output (AES3 or BLU link), the binary coded audio was not the same as what came from the server. When we did a BLU link output, we made the JSD the clock master for the BLU link network so we did not have to either sync the DSP in the JSD to the BLU link network or put sample rate converters between the DSP and the BLU link FPGA. It SEEMS that if we want transparency through the digital audio system, we should sync everything to the audio source (the digital cinema server). If we want to use another source for sync, we need to either sync the digital cinema server to that (slightly changing playback speed) or put sample rate converters at clock boundaries. Some signals carried over AES3 do not survive sample rate conversion. The SMPTE digital sync used to sync external immersive sound processors does not survive sample rate conversion. The SMPTE (Dolby) FSK sync generally does survive sample rate conversion, but sample rate conversion is not recommended.

On streaming audio stuff, I put a FIFO buffer receiving the stream, then pull the audio from that for playback. The playback speed is varied slightly as the FIFO "fullness" varies.

Digital audio clocking is fun!