CP850/CP950A/IMS3000 AES67 Output

[Chris Horak]

The CP850/CP950A/IMS3000 w/ audio processing can utilize AES67.

Has anyone here successfully used any of CP850/CP950A/IMS3000 with a Dante receiver (in AES67 mode), and can you speak to your experiences with that? Did you have to take any special steps? Did you have to use RAV2SAP?

I've read through a few older threads on this forum and it seems the general opinion is that it's theoretically possible, but not "plug and play." Some mentions of the Dolby devices needing to be clock leader due to Dolby's implementation of AES67. Some mentions of different versions of PTP causing issues, and various other clocking issues.

What's the consensus in Q3 2022?

[Steve Guttag]

I don't think you are going to get a consensus. My lack of familiarity with Dante and how it handles straight up AES67 while in that mode prevents me from commenting further about that aspect. Dante uses PTP v1 while AES67 uses PTP v2. One also has to be careful of their QoS configurations as Dante and Dolby are not using the same DSCP values. Dolby is using a more traditional DSCP for AES67.

For starters, you can pretty much forget about the CP850 ever playing nice with a normal AES67 device. It is certainly doable if things are precisely configured and yes the Dolby product will need to be the GM clock. My experience is with configuring a Dolby Atmos processor with a Q-SYS DSP processor. QSC went out of their way to have dedicated Atmos receivers to ensure things are configured just-so. As such, it should be possible to set up an AES67 receiver to mimic that, if you get things just right. Still, processors like the CP850 will never be set up to work with something else being the GM clock.

I believe the current version of firmware for the CP950/CP950A can work with external PTPv2 clocks. I have not tried it so I cannot comment. The IMS3000's current release firmware does not allow for an external PTPv2 but I hear that Dolby plans to update the AES67 implementation on the IMS3000 so that may not always be the case. I would say that anyone that proclaims that it is sussed out completely is probably not correct.

I can say that I have worked with an IMS3000 and Q-SYS with the (Q-SYS AES67 transmitters are feeding the Dolby DMA amplifiers) Dolby DMA amplifiers on surrounds and it is working (and about 99% stable). However, on the site I'm doing this, the IMS3000 remains the PTPv2 GM. Every once in a while, one of the streams may go missing on the DMA...resetting the AES67 transmitter seems to fix it every time (toggle the enable for that transmitter). Since power cycling the amps daily with the rest of the system has not had an incident of a missing stream.

So, back to your subject. I would say that there are no guarantees that the Dolby AES67 implementation is stable for use beyond the documented Atmos configurations. That, likely, the latest CP950 firmware has a degree of compatibility but I'd build a proof of concept before specing it and then having to come up with work-arounds. And even if you get it working, be sure to check it over time to see if you get any drift that will bring you into failure.

[Chris Horak]

Hi Steve, helpful as always, thanks! I believe we're going to explore this further so I'll update this thread if I come to any useful conclusions...

[Dave Macaulay]

I'm about to dive into using AES67 from a CP950 into QSys. Hoping for the best.
I have used AES67 for Atmos from a CP850 into JBL DSi-D amps, and managed to get it working with lots of help fromJBL and Dolby. Dolby's AES67 is NOT Dante and the configuration hurdles to get the Dante amps to play the sound were considerable. I still have lots of questions.

[Harold Hallikainen]

Didn't the CP850 originally have an "ATMOS Connect" output which was Harman BLU link? We made a D/A for it ( http://ftp.uslinc.com/Products/DAX-1...1.4_141003.pdf ).

Harold

[Marin Zorica]

850/950 can work P&P either as ATMOS connect to DMA amplifiers or BluLink to any amplifier with blulink, on CP you just chose which one you want. And next is custom where you can custom select ports etc. I know some who did try to run output of dolby AES67 and worked, don't know how stable it was......

[Marcel Birgelen]

I wouldn't call the CP850 compatible with AES67, but there are known-to-be-good configurations: I know some have had AES67 working, but there are zero guarantees and if it works, it doesn't work out of the box. QSC Q-SYS will work, but QSC put in some efforts to make it work. Anything labeled with Harman BluLink should also work without too much problems.

I've tried to hook our CP850 up to a Dante device once, but even after some hours of tweaking and messing around, that wasn't a success story.

[Leo Enticknap]

Didn't the CP850 originally have an "ATMOS Connect" output which was Harman BLU link?

It was, and AFAIK still is, switchable between AES67 and BLULink. If I remember correctly, on earlier firmware versions, BLULink was the factory default and you had to change it if you wanted AES67, but on the current one it's the other way round.

I'm likely going to be doing a project involving a CP950 and LEA Professional Dante/AES67 enabled amplifiers in the near future, so the above is very useful - thanks folks.

[Chris Horak]

It was, and AFAIK still is, switchable between AES67 and BLULink. If I remember correctly, on earlier firmware versions, BLULink was the factory default and you had to change it if you wanted AES67, but on the current one it's the other way round.

I can confirm this is exactly accurate. Let us know how your project goes Leo!

...I know some who did try to run output of dolby AES67 and worked, don't know how stable it was......

This is where I am...theoretically it should work...but is it a good idea?

[Pete Naples]

Dolby, in a typical Dolby stylee, use 'unusual' PTP domain and UTP ports. That's fine between a CP950 and Dolby amplifiers, a third party device talking to a CP950 in AES-67 mode then the chances are that PTP domain and UDP ports will not match

[Steve Guttag]

Actually, Dolby can work with the domain you put in. For instance, in the systems I set up, I choose the domain as 100+screen number. So, for theatre 1, I would use domain 101. There is no problem with that. I have theatres with domain 101, 102 and 106, thus far. The Dolby default is 109 but that is changeable. Dolby also uses standard AES67 DSCP levels...it is Dante that changes the PTP DSCP level. Now, Dolby reacts poorly to IGMP snooping (we'll it doesn't react so it gets shut off to Dolby network ports if you don't force them on). This would only affect systems that use IGMP for multicast, like Q-SYS.

But yeah, I take you point that Dolby, at least at first, only thinks of Dolby so...without any special networking, one can connect a Dolby sound processor directly to a Dolby DMA or use a simple non-managed switch to connect to multiple DMAs. So, for the loyal Dolby customer, they don't even have to think about all of this AES67 business. Remember, that is going to cover a VERY large percentage of the install base too.

Mind you, I'm not defending Dolby not doing a proper AES67 implementation, just rationalizing how it came to be. They do seem to be making strides on improving things on the current products.

[Marcel Birgelen]

I guess most of us would want to see a Dolby that would conform more to open industry standards, especially because the professional audio industry has long since adapted AES67 and Dante as defacto standards for network-based audio distribution. But to their defence, I never remember them claiming any of their processors to be compatible with AES67 and/or Dante

[Steve Guttag]

Personally, I don't see any point in adopting Dante in a cinema environment. Why go for a proprietary system when an open system is available? In fact, one of the hardest hit by the supply chain issues is Audinate and thereby Dante. Everyone has to source their Dante chips from a single source...that's a bottleneck that need not be. I get that the A/V world has been using it but not the Cinema one...and, whereby is it is only mostly compatible with AES67...why support both. Anyone that can make a Dante audio device can make it as AES67 and skip the cost and supply chain issues associated with Dante.

That is sort of the problem with Dolby's AES67...they only thought, at first, at least, about ensuring it works for just their stuff. If they fully embraced the AES67 requirements, it would already work with every other AES67 device. Again, they're getting there. Dante would just throw another, unnecessary wrinkle into the mix. Thus far, where I've used Dante, I've used a Dante bridge to take the incompatibilities out of the mix.

[Marcel Birgelen]

I agree that I'd also rather see AES67 being adopted as the de-fector standard in cinema environments than Dante. Dante simply has the distinguished advantage of being "first" and therefore has found quite a foothold in the professional A/V space, whereas protocols like CobraNet never really made an impact.

I don't think we'll ever see official AES67 support for the CP850, but I still expect updates for the IMS3000 and CP950(a) in the near future.

[Pete Naples]

I have sent CP950 into a large theatre PA system via AES67, because going analogue would have meant manual patching. Once the Dolby esoteric PTP and UDP were set to match the installed system, it worked. All patching/routing is taken care of in the digital domain via a preset stored on their system. I'm not really familiar with that side of it, the house sound engineer took care of it.

I've done Atmos from a CP850 into Crown DCiN series amplifers, that was quite a while ago. No one could tell me for sure that it would work. Which it did and has been flawless for several years.