Announcement

Collapse
No announcement yet.

Ethernet Switches

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    "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.

    Comment


    • #17
      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.

      Comment

      Working...
      X