Completely bizarre audio sync issue: IMS3000/CP950A/Q-Sys

[Leo Enticknap]

I'd be interested in everyone's take on this one. There appear to be gremlins in the booth of a Bel-Air Circuit residence theater I look after. The system consists of an IMS3000 in server mode feeding "Atmos Connect" AES67 to a CP950A and thence to a Q-Sys core. In parallel is a JBL SDP-75 (aka the "Consumer Trinnov") that handles alternative content. The two processors converge in Q-Sys, which handles switching between them. Tuning is also done in Q-Sys, and those are its only two significant functions.

Yesterday I got a call out of the blue from the owner's assistant, complaining that the audio was badly out of sync. My first question was "DCP audio, alternative content audio, or both?" DCP only, came the reply. "Just one DCP, or more than one?" Every one I play, came the reply. Those answers, to me, tended to give Q-Sys an alibi (there is no audio delay component in the Q-Sys design at all), and point the finger at either the IMS3000 or the CP950A.

So I rebooted both remotely, plus the Q-Sys core just to be thorough about it. No change. We then troubleshot, with me adjusting the delay in the IMS3000 via Teamviewer while she looked at a sync test DCP. We eventually got it back in, but I had to add a 350ms audio advance (i.e. "-350" in the audio delay field) before it looked and sounded right to her. Previously, it had a global delay of 95ms, which is what had been programmed on installation. The CP950A was on its factory default delay of 80 for all the DCP macros.

She absolutely assured me that no-one else had f****d with the system since I last PM-ed it in February. In case this is relevant, the Q-Sys core is on 9.4.6 LTS, the IMS3000 is on 3.5.20, and the CP950A is on 2.2.0.4.

Has anyone else experienced anything like this - sync suddenly jumping out for no apparent reason?

[Marcel Birgelen]

Just curious about some of the decisions made in this setup:

- Why does the IMS3000 feed into the CP950A instead of directly into Q-Sys?
- And by extension: What's the actual function of the CP950A, if you have an IMS3000 capable of doing Atmos and a JBL SDP-75, much more capable of handling alternative content?

It's hard to do an armchair tele-diagnose on this, but the weird thing is that you went from a global delay of 95, to an advance of 350 on the IMS3000. Implying one or a combination of the following things:
- The delay of the rest of the audio chain has increased by roughly 450ms
- The delay of the video playback has increased by roughly 450 ms

What's also strange is that a reboot doesn't clear the issue, pointing at a permanent change somewhere.

My first hunch would also be a problem between the IMS3000 and CP950A, simply because my lack of trust in "Dolby Connect", given the amount of issues this has caused in the past.
Furthermore, I'd check if the IMS3000 is healthy and there isn't a faulty disk/SSD in the RAID causing all kinds of havoc.

[Leo Enticknap]

This install was done years before I had anything to do with it, and so I can't explain the decision making rationale. However, this isn't the original equipment. The server was originally a DSS200 and the processor was a CP850. When the projector was upgraded from a DP4K-P to an SP4K-27BHC, the player was upgraded to an IMS3000. Some time later, the CP850's media block battery died with no warning (despite it being left on 24/7), and a power brownout killed it. At that point it was upgraded to the 950A. We decided against the audio & Atmos license for the IMS3000 route, in order to include a backup for HDMI audio input in the rack, in case the SDP-75 were to develop a problem (there is no DCIO in the Q-Sys setup).

There are no RAID errors detected, but there is some weirdassery in the log analysis:

image.png

I'm wondering if nuking the RAID (external NAS) and reinitializing it is worth a try. She's got about 6 TB of stuff on it, though, most of which is likely important, and so reingesting it all would be a pain.

[Steve Guttag]

As for the logs, Doremi logs always have "weirdassery" in them. If concerned, I'd ask Dolby Tech support. Naturally, I'd ask them about the audio latency. How is the CP950A feeding Q-SYS? I'm guessing AES67 using the dedicated "Atmos" receiver blocks?

I do agree with Marcel on the curiosity of going with a CP950A when the IMS3000 has the Atmos aspect covered as well as an HDMI input that will decode consumer Atmos too. I'd also use the DCIO-H, if an HDMI in the rack is that big of a concern (plus it would give you an unmolested AES3 audio path). In fact, all of my Atmos systems have a DCIO-H in the rack as that provides network redundancy too. AES3 is rock solid and I use a conventional audio path for it. It would have given you a means to check the sync. I had to do that before 3.5.20 came out when there was a feature that due to the CPL listing the starting point 20-seconds off had the audio out of sync by 20-seconds (AES3 was correct, Atmos was off).

Another means of dealing with HDMI is Extron's SSP200 (and they don't have the political issue of Dolby or DTS...it's got both and can go up to consumer Atmos/DTS-X). Not to mention, the Trinnov...er JBL piece has a plethora of HDMI inputs.

Since they use AES channel 14 for sync to the CP950A, I'd start my quest on that one...how good is that signal? If you skip the ATMOS signal and force straight up 5.1/7.1 is the lip sync issue still there? Since you have remote capabilities, have you used "hovermon" to listen to the audio coming in on the Atmos receivers and compared it to something on the output to convince yourself that there is no delay in there that snuck in or was forgotten about?

Other than the one incident listed above, I have not had any lip sync issues on my IMS3000s with or without Atmos. Then again, none of my CP950s have had lip sync issues either (the only CP950A I've put in was in a screening room for "Dolby Cinema." There haven't been sync issues reported but that isn't using the IMS3000 server either. We do have a DCIO-H on that system and we sent the AES3 cables into a splitter so both the CP950 and the DCIO-H get the AES3 feeds.

[Leo Enticknap]

Yes, Atmos receiver blocks in the Q-Sys design.

Good suggestion to switch between Atmos and regular AES, to determine if the delay is specifically Atmos-related. Will do the next time I'm on site. There is no DCIO-H in this system (both AES3 and "Atmos Connect" go into the 950A), and so that isn't an option, in the short term at least.