I can believe it. Dolby doesn't like to play with others well. If their stuff works with each other, mission accomplished. If it works with others...it's a bonus. That isn't to say that Dolby won't try to work with others but that definitely isn't their focus.
Announcement
Collapse
No announcement yet.
Q-SYS Corner
Collapse
X
-
Agreed! Not working with IGMP or following a different PTP clock is silly. Heck, a site should be able to put in a dedicated PTP clock and have everything track to that. But my experience has been that when Dolby has to play with others on AES67...it is marginal, at best. For Dolby Atmos, QSYS has dedicated Atmos receivers that are specifically designed to work with Dolby's AES67 feed. However, when it comes to working with, say, their DMA amplifiers...it sorta works. I wonder if I could convince Q-SYS to make dedicated AES67 transmitters to work with their amplifiers. I doubt it because Q-SYS wants you to use their CX-Q amplifiers...which I get. In fact, I found out about the DMA problem because I couldn't get CX-Q amps in time for a theatre opening (supply chain issues). That said, I don't need 50 some amplifier channels with analog inputs that we're having to pay for either. The DMA can be a more cost-effective alternative.
Comment
-
Does the CP950 lock to the AES3 coming from the media block? If there is a separate PTP source, can everything, including the media block, lock to it? Back in the old analog television days, everything would "gen lock" to a sync source so you could switch smoothly between sources. Unless everything is on the same clock, it seems like there has to be sample rate converters in there somewhere to deal with the ever so slight difference in sample rates between different pieces of equipment. The USL sound processors have sample rate converters on all the AES3 inputs so the DSP would not have to try to follow the incoming sample rate. So, can a projector/server/media block sync to a PTP source? Does it need to?
Comment
-
Thanks! So, it appears the server/media block is the master clock for the entire system, at least when AES3 audio is being played. And, I guess also when IAB is being played since the sync signal is carried as FSK on an AES3 output. Of course, I expect all the pairs to be at the same sampling frequency, but they MAY not all be precisely phased together. I think that was the cause of "robosound" on a previous processor (CP650?). USL made an inline sample rate converter to, ideally, fix that. So, unless the server/media block can be synced to an external PTP server, I think it makes sense for the CP950/850 to be the master clock of the network audio since it is passing through the clocking of the server/media block. Projectors CAN be synchonized using SMPTE 12 timecode, but, I believe, that is only frame accurate, not audio sample accurate (and why we have the FSK and binary sync protocols on AES3 for external IAB rendering systems).
Comment
-
There are problems using the CP950A or IMS3000 as the PTP clock...first off, those products have their own boot cycles and can cause the rest of the AES67 system have to jump to a different GM. If one has multiple Atmos/IAB theatres, you now have to have multiple networks (or domains, really) so since they all have to have their own clock rather than having a single GM that could be more stable for the complex.
With an IMS3000, since the rendering is done on-board, no external AES3 sync is needed...just the AES67 stream is used. I run AES3 as well for backup reasons (as well as handling 2.0 sound formatting that vidiots (and advertising provide). With AES67 it is a single cable/network so the DCIO-H with redundant networking, plus the AES3 audio is far more robust a system so a premium theatre never goes down. When I've used the CP950A, I used a passive AES3 splitter to feed the AES3 to both the CP950A and the DCIO-H.
Comment
Comment