CP850/CP950A/IMS3000 AES67 Output

[Marcel Birgelen]

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.

Crown is part of Harman and as such those DCI series amps support BLU-Link, which is officially supported by the CP850 and which is the default mode of the Atmos Connect interface on the CP850.

[Chris Horak]

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.

This is certainly very reassuring— thanks Pete!

[Dave Macaulay]

"Crown is part of Harman and as such those DCI series amps support BLU-Link"

Well. being part of Harmon does not guarantee BLU-Link compatibility.
JBL is also a part of Harmon. (which is part of Samsung, if anyone cares)
JBL DSi-2D amps (their DSi-2 amps with digital inputs added) are pretty much Crown amps inside: the boot splash on the display says Crown (this may have changed with newer amps).
They use Dante/AES67 for their digital inputs, NOT BLU-Link. They do not accept BLU-Link.
I'm not sure if these support the full Dante protocol. The CP850 definitely does not, but AES67 is the transport layer for Dante so you can get the 850 and DSi-2D amps to work together. I haven't tried with a 950 yet.

[Marcel Birgelen]

"Crown is part of Harman and as such those DCI series amps support BLU-Link"

Well. being part of Harmon does not guarantee BLU-Link compatibility.

No, it doesn't guarantee it, but the specs sheet should. All Crown DCi amps do support BLU-Link.

We're not doing a lot of Crown though. I know the brand has its fans, but we standardized pretty much on QSC.

JBL is also a part of Harmon. (which is part of Samsung, if anyone cares)
JBL DSi-2D amps (their DSi-2 amps with digital inputs added) are pretty much Crown amps inside: the boot splash on the display says Crown (this may have changed with newer amps).
They use Dante/AES67 for their digital inputs, NOT BLU-Link. They do not accept BLU-Link.
I'm not sure if these support the full Dante protocol. The CP850 definitely does not, but AES67 is the transport layer for Dante so you can get the 850 and DSi-2D amps to work together. I haven't tried with a 950 yet.

Interestingly, their DSi spec sheet claims Dolby Atmos Connect compatibility after a "firmware update", I guess that will flash the version back that does support BLU-Link instead of AES67 and Dante compatibility.

[Sean McKinnon]

Interestingly, apparently JBL makes their own cinema processor? Has anyone ever used it?

[Dave Macaulay]

"flash the version back that does support BLU-Link"
This does not appear to be an option.
The amplifier firmware update for using a CP850 Atmos Connect with AES67 is in two parts: the amp's main firmware and its separate Dante firmware are both updated, both upgrades arecdone through Audio Architect rather than using the Dante upgrader from Audinate for the AES67 subsystem.
A CP850 has to be changed to AES67 from BLU if it's on BLU. That seems to be fairly complicated as the 850 takes a long time to switch over.
I haven't set up a 950 for this (coming soon!) - the documentation plus advice from Dolby say it should be similar. (The last system we did with ATMOS and JBL DSi-2D amps using AES67, we opted to use the just discontinued CP850 as we could not get absolute assurance that a CP950A would work that way - we had proven the CP850 would)
They (JBL) want a dedicated managed switch with some specific settings for the AES67 distribution to the amps from the Atmos Connect out port.
Then the CP850 AES67 settings get configured to talk to the amps, finally the amps get switched to digital input and then each channel input (these have 4 channels with 1&2 or 3&4 bridgeable so there can be 2 to 4 inputs) set to one of the AES67 signal channels using Audio Architect.

Then you hope it works.

Note the Crown DSi series has been discontinued - that amplifier series has been superseded by the JBL DSi-2 series, available with analog inputs only or with analog and AES67 digital inputs in their D models. Cinema focussed products from Harmon look to be migrating to JBL branding now.

[Pete Naples]

Interestingly, apparently JBL makes their own cinema processor? Has anyone ever used it?

No TOSLINK/SPDIF/HDMI input.

NO RJ45 connectiosn for AES

[Marcel Birgelen]

"flash the version back that does support BLU-Link"
This does not appear to be an option.
The amplifier firmware update for using a CP850 Atmos Connect with AES67 is in two parts: the amp's main firmware and its separate Dante firmware are both updated, both upgrades arecdone through Audio Architect rather than using the Dante upgrader from Audinate for the AES67 subsystem.
A CP850 has to be changed to AES67 from BLU if it's on BLU. That seems to be fairly complicated as the 850 takes a long time to switch over.
I haven't set up a 950 for this (coming soon!) - the documentation plus advice from Dolby say it should be similar. (The last system we did with ATMOS and JBL DSi-2D amps using AES67, we opted to use the just discontinued CP850 as we could not get absolute assurance that a CP950A would work that way - we had proven the CP850 would)
They (JBL) want a dedicated managed switch with some specific settings for the AES67 distribution to the amps from the Atmos Connect out port.
Then the CP850 AES67 settings get configured to talk to the amps, finally the amps get switched to digital input and then each channel input (these have 4 channels with 1&2 or 3&4 bridgeable so there can be 2 to 4 inputs) set to one of the AES67 signal channels using Audio Architect.

Then you hope it works.

Sounds like a cumbersome and complex process for something that should be as easy as plugging an RJ45 cable between two devices...

I guess the managed switch is necessairy to make the IGMP/multicast work between both devices?

[Sean McKinnon]

No TOSLINK/SPDIF/HDMI input.

NO RJ45 connectiosn for AES

yeah, figured it would be less than stellar

[Serge Preo]

Similar problem here.
Trying to set up the CP950 to send 5.1 output via AES67 into an Allen & Health SQ Dante 64x64 chip mounted in the back of an Allen & Heath AHM-32 Matrix processor.
https://www.allen-heath.com/hardware...g/sq-dante-64/
https://www.allen-heath.com/hardware/ahm/ahm-32/
Then the goal is to have the analog outs of the AHM-32 distribute to auditorium speakers.

We have everything connected and the CP950 is taking in audio and appears to be sending a lot multicast packets.
However the step that we are stuck on is being able to see the AES67 output of the CP950 within Dante Controller - it simply won't show up.
As advertised, we should be seeing an AES67 flow from the Dolby like so:
https://youtu.be/a_xS-n6itSQ?si=4Heui-j9AWkpfrBv&t=200

Please let us know if anyone has ideas!

[Marcel Birgelen]

I guess it remains a bit of a hit-and-miss.

You're talking about 5.1 and Atmos, which is a bit confusing. For Atmos, you need a CP950A, for example, not a vanilla CP950. You're referring to the Dolby CP950 when you're referring to "the Atmos"?

Have you checked this video? It contains some vital settings like the correct multicast address and RTP/RTCP/PTP port numbers.

[Serge Preo]

I guess it remains a bit of a hit-and-miss.

You're talking about 5.1 and Atmos, which is a bit confusing. For Atmos, you need a CP950A, for example, not a vanilla CP950. You're referring to the Dolby CP950 when you're referring to "the Atmos"?

Have you checked this video? It contains some vital settings like the correct multicast address and RTP/RTCP/PTP port numbers.

Correct and apologies - I just made an edit to now say "the CP950".

I did view the video just recently.
From 12:07 https://vimeo.com/435856534#t=727s

In order for the CP950's multicast flow to actually be discovered in Dante Controller,
I wonder what the what the settings should be for the
Source UDP port,
RTP Destination UDP port, and
RTCP Destination UDP port?
The video mentions that at least the first two should be set the exact same way on both ends.

As far as configuring on the Dante end, Audinate only seems to mention to use 5004 for the UDP port, using AES67 multicast, but doesn't specify 2 values as per above.
https://www.audinate.com/learning/te...o-your-network

[Marcel Birgelen]

Both AES and Dante uses a whole slate of ports and there even is a difference between multicast and unicast streams for some of the traffic components, like the RTP streams,

Keep in mind that Dolby uses multiple RTP streams with increasing port numbers. If those don't match between your CP950 and AES67/Dante bridge, there will be no incoming audio. I think the default for AES67 is indeed 5004, which is different for Dolby. For PTP, Dolby seems to use the default UDP port. RTCP usually isn't needed but it usually uses the next odd-numbered port available, with regards to the RTP port, so the default port is UDP/5005.

For PTP there is another challenge: Dante uses PTP v1 whereas AES67 uses PTP v2. I'm not sure about the CP950, but both the CP850 and IMS3000 don't let you specifically choose the PTP protocol version on the "Dolby Atmos Connect" side. In any case, I think you should let the Dolby end be the master clock source.

I've only used "AES67" with Dolby's CP850 and IMS3000 in combination with QSC Q-Lan, on which QSC spent some efforts to make it work...

[Marin Zorica]

Recently I have combination with CP950A, dolby DMA for side and top surround and powersoft quattrocanali for screen channels. Dolby DMA is feed true AES67, while powersoft did go analogne. Powersoft are version with AoIP AES67, so I give it a try, since i did not have much time and allready it was set to go analogne, but i was wondered to have it a try. I did not get audio to powersoft, I have tried different ptp, ports, multicast adress but nothing, while in same time dolby DMA amplifier did receive audio without problem. I have used netgear m4250 which I did used in other dante/aes67 /q-lan and newer had issues. Even i did try to direct connect cp950 to powersoft but nothing. The thing i have notticed is that when i connect dma and cp950, dma receive audio and is in clock, in same time when i connect powersoft to switch dma is not receiving audio any more and clock indicator on dma is off. I did tought something with ptp priority is problem, since clock is down while powersoft are connected. Powersoft have little about settings for aes67 (discover is by sap, and you just have ip that you can change). On other hand for example qsc have wide range of settings for aes67 receiver so you can try to match them with cp950, which, is working as someone say in previous post. Too bad I did not have much time to try other things, but maybe next time when I have cp950 at hand. Also I did try dante controller which cannot see any cp950 stream, and even rav2sap (software tool made by ravna do pair aes67 devices) did not saw cp950 either.

[Steve Guttag]

With Dolby stuff, you have to be careful on your networking. Things like IGMP do not work with Dolby components. They won't respond and shut down that port on the switch. One has to force-on all ports talking with Dolby equipment.

Then there is the whole clocking thing. It has been awhile since I last experimented with letting something other than the Dolby processor be the GM PTP clock. I got it working but it was sketchy with errors showing. One also has to check it over time to ensure there are no cumulative drifts.

So, with that in mind, one has to set up the Dolby sound processor (IMS3000, CP950) to ensure it "wins" the GM clock arbitration. Ensure that the Domain matches. Ensure that the Source UDP and Destination RTP ports match the device that are to receive the audio. Make sure you are on the same multicast network.

It is real easy to miss one of those and you won't have AES67 audio.

Dolby uses standard AES67 DSCP levels so, if you have Dante, and you configure your network switches for QoS, the GM clock will not be at the highest DSCP level and you can get clock jitter as Audinate puts audio on what is normal PTP DSCP level. There are those that feel that with the high bandwidth switches like the Netgear A/V series stuff that it negates the need for QoS since it will get the clock out without latency. This is probably true, unless you are using that switch near its capacity (for bandwidth), which is where QoS really comes into play. Dolby uses simplifying assumptions like...only their stuff is on the AES67 network so the sound processor is just talking to less than a handful of devices...all with the Dolby badge...so everything is configured correctly. You don't even need a managed switch with that sort of set up since there is nothing to conflict.

I have set up (successfully) a system such that there is an:

IMS3000 (as the audio processor for DCPs) -> QSYS -> QSYS amps AND DMA amps.

The IMS3000 is the GM clock whenever the IMS3000 boots up, the QSYS core (110f) is the GM clock when the IMS3000 is off. The QSYS amps (CX-Q) are connected directly to the QLAN switches (dual network) and the DMA amps are connected to QLAN-A and are fed via QSYS AES67 transmitters. The only time the system freaks out is when the IMS3000 wakes up each morning and takes over the PTP clock as everyone loses clock sync. The DMA amps do not talk to the IMS3000 directly. The DMAs are feeding all of the surrounds and surround SUBs. The CX-Q amps are behind the screen (behind the baffle wall) feeding the screen channels and the main LFE subs.

The network switches (TP-Link TL-SG2428P), for all of the Dolby products have their ports set to "static router port" to allow them to survive IGMP queries. And, for good measure, via SNMP, we poll the DMAs for good AES67 "lock" as well as the streams. Every once in a while, I'll see that a single stream will drop for some unknown reason (the AES67 lock and other streams will be fine). The other odd thing is SNMP may indicate a dropped stream but when logging into the amplifier, the stream is good and there are no issues (bad SNMP information).