Q-SYS Corner

[Steve Guttag]

Q-SYS 9.4.5 LTS has just been released. As will be the case with the LTS branch, not many new features (just the updated limiter parameters for the Generic Speaker block (non-QSC speakers). The rest are bug fixes.


What's New in 9.4.5 (LTS)

Version 9.4.5 is a Long Term Support (LTS) release of Q-SYS Designer Software. It includes these updates and resolved issues.

Note: See the Downgrade Notices section for important information concerning downgrading to version 9.4.5 (LTS) from version 9.5.0 and later.

Loudspeakers

Generic Speaker: New limiter parameters

The Generic Speaker component includes new properties for Peak Attack (ms) and Peak Release (ms), allowing for additional customization of limiter parameters for low impedance loudspeakers not manufactured by QSC.

To learn more about these and other limiter parameters, see the Generic Speaker topic.

Control

TSC-G3 Series: Hardware update

Q-SYS v9.4.5 and later (LTS branch) and v9.7.0 and later (mainline branch) now support updated LAN controller hardware in TSC-G3 Series touch screen controllers.

Resolved Known Issues

• Audio: An issue that could cause "Packet Missing Streaming Errors" from QIO audio devices on networks with heavy traffic has been resolved.
• Amplifiers: An issue that could cause CX-Q amplifiers to stop passing audio while Status is "OK" has been resolved.
• Amplifiers: The CX-Q amplifier Limiter threshold for peak speaker limiting has been corrected when the amplifier is in any bridged mode. The Limiter value for peak speaker limiting is now properly indicated in the Generic Speaker component.
• Loudspeakers: Limiter settings have been corrected for some older Q-SYS loudspeaker models in 70V/100V mode.
• Loudspeakers: Details for the AD-S112sw loudspeaker are now shown in the Inventory list.
• Loudspeakers: Logs no longer print out "100V!" and "70V" when a Generic 70/100V Speaker is in the design.
• Video: An issue that could cause USB bridged audio and video from an NV-32-H Encoder to a Mac to eventually stop has been resolved.
• Control: An issue that could cause TSC and TSC-G2 Series touch screen controllers to show "no link" when connected to certain network switches has been resolved.
• Control: SNMP requests in scripts no longer cause increasing memory usage and eventual Core unresponsiveness.
• Control: Frequent camera switching in Mediacast Router no longer results in UCI Viewer or Q-SYS Control for MTR app instability when connected to a Core via LAN B or AUX LAN.
• Platform: An issue that could cause UCIs to not be discoverable in the Q-SYS Control iOS app when a Core's LAN A and LAN B interfaces are both connected to networks has been resolved in Q-SYS 9.7 with app version 3.6 and later.
• Platform: An issue that could cause a Core 3100/1100 front panel error after reboot has been resolved.

[Steve Guttag]

QDS 9.8.0 has just been released. This is the cutting edge branch (more features but with more "bugs"). In general, I recommend the LTS branch for cinema (and any other discipline that does not need a new feature.

At present, the new CORE 610, which, essentially, replaces the CORE 510 is not, at present supported in any of the LTS versions, so, one will need to look to a later version for support, like QDS 9.8.

Things that 9.8 brings that may pertain to a cinema system include:

• The ability to use some COREs as peripherals. To me, this seems like an expensive way of getting analog I/O but perhaps in the right application, it makes sense. Since Q-SYS is really downplaying the network redundancy, using a CORE Flex-8 or even a CORE 110f as an I/O box could be a means to retain network redundancy and get quite a bit of analog I/O that, previously, would have been an I/O frame with cards. Cost wise, two Q-IO boxes are significantly cheaper than an CORE Flex-8 but they lack network redundancy. It would take 6-7 Q-I/O boxes to replicate the analog I/O of a CORE 110/110v2 (the 7th Q-IO would be for GPIO)...a CORE 110 is going to be cheaper than that and it has network redundancy plus USB bridging. The question then is, what are you using as a CORE where a CORE 110 in I/O mode makes sense? Perhaps the CORE 610, that has no analog I/O.
• The SPA-Q amplifiers (come in 2 and 4 channel 60-watt/ch versions). The SPA amps have been fine utility amplifiers in their own right and can be used for lobby, bathroom, VIP room and even booth monitors, The SPA-Q line omit the need for analog inputs and, even better, they come with 2-channels of FLEX analog plus some GPIO. So, in one little box you might get the analog I/O you need as well as utility amplifier. The BIG downside is that they are not network redundant. But, if you have a VIP room, two 4-channel amplifiers is just 1U tall (they are only ½ a rack wide) so you can feed a full 7.1 sound system in there where 60W/CH is likely sufficient and even if you have a self-powered Subwoofer, their Flex-IO should suffice for that too.

Here are the full release notes:

What's New in 9.8.0

Version 9.8.0 includes these new features, updates, and resolved issues.

Platform
Core 110f: Peripheral Mode support
Core 110f: GPIO "Optional" property
SPA-Qf Series Network Amplifiers
Deprecated: Windows 8.x support
Updating firmware: Enhanced pop-up message
Default NTP servers updated to match NTP.org
Q-SYS Help: Online-only by default

Audio
I/O-8 Flex: Improved Mic Detection
NM-T1 Remote Mode enhancement
Parametric Equalizer enhancements

Video
Generic AV Source: new "Video Format Error" drop-down

Control
Call Sync enhancement
UCI Variables tab added to User Control Interfaces in Q-SYS Designer Software
Edit menu: "Search and Replace"
Asset Manager: "Reflect Enabled" badge
Asset Manager: "Q-SYS Tools" filter
Lua WebSocket protocol
Tools menu: Added "UCI Operations" category

Management
Enterprise Manager: System notes and attachments
Enterprise Manager: Presets enhancement
Enterprise Manager: Alerts & Notifications enhancements

Resolved Known Issues

• Audio: An issue that would cause AES67 audio from a third-party Dante to show error "Compromised - Packet Missing" has been resolved.
• Audio: An issue that would cause the NM-T1 Status component to output errors in a Compromised or Missing state has been resolved.
• Amplifiers: An issue that could cause CX-Q amplifiers to stop passing audio while Status is "OK" has been resolved.
• Loudspeakers: Updating a loudspeaker component's Model to AD-P.SUB in the schematic no longer causes an error.
• Loudspeakers: Designs that have an NL-SB42 no longer cause an error when choosing to Save to Core & Run.
• Video: An issue that could cause the USB Video Bridge component to not re-populate in the inventory list after being deleted / removed has been resolved.
• Video: An issue that could cause NV-32-H to no longer receive embedded audio from HDMI has been resolved.
• Control: An issue that could cause TSC and TSC-G2 Series touch screen controllers to show "no link" when connected to certain network switches has been resolved.
• Control: An issue that could cause Trigger State button presses to not respond to left mouse clicks within UCI Viewer has been resolved.
• Control: An issue that could cause SNMP read values to truncate over 100 characters has been resolved.
• Platform: An issue that could cause Non-Redundant Dante endpoints to not be discoverable in a Redundant CDN64 Receiver has been resolved.
• Platform: An issue that could cause all input sources to play through a Virtual Page Station message has been resolved.

[Christopher Cain]

Is anyone using the DCIO-H in a professional Cinema? We have a Barco SP4K feeding the DCIO via AES and an HDMI output of an NV-32 into the same DCIO. I'm wondering what the experiences are from other users. We had been experiencing frequent random audio dropouts from apparent Package loss events using the HDMI input and I witnessed one isolated issue from a DCP playback. 2 days ago the DCIO went offline and now won't load or be recognized in the design. The DCIO is the only component that is exhibiting the Packet loss issue.

[Leo Enticknap]

I've installed them in several professional cinemas, including the Alamo Drafthouse 12-plex in Downtown LA in 2019. There have been no issues with the DCIO-Hs specifically that I'm aware of. The fact that you're experiencing glitches on both HDMI and DCP playback through the DCIO-H, but not with any other audio source going into Q-Sys, does suggest to me that there is a hardware issue with the DCIO-H or its connection to the Q-LAN.

I'm guessing that you've tried power cycling it. What does the front panel display tell you? Can you ping its address from a PC on the Q-LAN (primary and secondary, if you have dual redundant Q-LANs)? If the front panel display looks normal and you can ping it, then maybe we're looking at a bad port in a switch (try plugging it into another one?), or another device has come online with the same IP address, or a networking issue along those lines. If the front panel display does not look normal, my money would be on a hardware failure with the DCIO-H, in which case I'm afraid that it would need to be RMA-ed to QSC for repair.

If you can get it communicating with the core again, looking at its status component in the running design could give you some clues as to whether or not there is a Q-LAN connectivity problem:

DCIO_status.png

[Christopher Cain]

Thanks Leo. The unit was working and failed in the middle of a screening. After that the status is "not found" in the V9.6 design. I performed a factory reset and renamed the device to the name in the design. Still "Missing" I can ping the device and open the Peripheral Manager. But per the front panel no design loads into the unit. It shows in the configurator too. I've tried different ports to the switch. Incidentally the DCP playback is 99'9% solid. The HDMI input is the path that had frequent packet losses. Hope you are well.

[Leo Enticknap]

Did you also change the IP address and netmask back to what it was? Without that, it will auto IP itself with a 169.254.X.X address, and the core won't be able to see it to push the design into it.

Suddenly crapping out in the middle of a show does suggest a hardware fault to me, I'm afraid.

[Christopher Cain]

All units are using DHCP. I don't manage the switch but I believe the IP address is being set by recognizing the MAC Address because it always boots with the same IP. The configurator sees it FYI.

In the meantime I need to support classes. I rerouted the HDMI audio directly into the virtual router and it works ( after an odd problem with the Center and lfe channel being switched on the Blu-ray. I heard track layouts were a standard. haha )

I need a solution for the DCP audio playback tho. I have a few spare QSYS IO's. So I'm looking for an AES to Analog converter. Maybe after that I don't need the DCIO. Thanks for your help.

[Leo Enticknap]

Configurator can see an address in a different subnet, but you can't fully connect it to the core until you've given it one in the same subnet. But if it's taken one from DHCP, is on the same subnet as the core, and has the same device name as is in the design, but it still won't download the design from the core and run, then this is adding to the evidence for a hardware fault.

If you have IOFrames, then a CIAES-16 card would enable you to get the audio from your Alchemy into Q-Sys. The problem is that they're not made anymore. Feel free to contact Jim at the office, who would be able to find out if QSC have any remaining in stock, and give you a quote for one if they do. If you simply want a digital to analog converter and to get the DCP audio into Q-Sys as an analog signal using existing hardware, something like a a Dolby DMA8+ would do the job (we have old but unused ones available).

[Christopher Cain]

Thanks Leo! You are a Film-Tech legend haha

[Steve Guttag]

I have a LOT of DCIO-H out there. Essentially, zero issues.

For lost/dropped packets, I'd be curious about the Switch and Core configurations. Does your switch have the proper QoS settings? Also, the switch DSCP settings have to match the properties settings in QDS (unless you have Dante on the network, it should be in "QSYS" properties, otherwise, "Audinate." The switch QoS settings HAVE to match with the right priorities and with strict priority. Furthermore, for things that "disappear" that normally points to improperly set IGMP. There should be a single IGMP querier on that network and all switches (including if the querier is the same switch) for IGMP snooping on all ports with multicast (QSYS) devices.

If you don't manage the switch, how well does the entity that does manage it understand the needs of Q-SYS? If you look at your event log...it should be solid and no indication of dropped packets.

I also suggest, unless you need to use something other than LTS versions, that you move away from 9.6 and slide into 9.4.4 (or, perhaps 9.4.5).

Also note, the NV32H does not transport bitstream audio, just LPCM...so, there is little point in bringing it out and back into the DCIO-H, just take the audio off of the NV-32H directly.

[Leo Enticknap]

Unless the settings on the switch were changed in the middle of the show during which the DCIO-H borked, I'm struggling to understand how bad switch settings could have caused this. Bad packets ever since the original install, yes, but all these problems suddenly appearing with just one device on the Q-LAN, and after many months of trouble-free operation?

[Jason Raftery]

Is anyone else having significant problems with QDS version 9.3.1?

I've got three systems at three different sites with 110f or 110c cores that went from being stable on 8.3.2 or 9.1.2 to being problem children on 9.3.1. The amps (DPA4.2/4.3/4.5 or DPA8.8Qn) will all go "OFFLINE" every 3-5 days for no apparent reason, requiring a power cycle of every amplifier from the physical power switch on the back of each amp to bring them back online and start passing audio again.

The core is oblivious when this happens, QDS and Configurator show everything is online and trigger no alerts, even each individual amp's web interface shows the amp is online when it isn't.

QSC claims no one else is reporting this issue and has yet to come up with a solution other than attempt to downgrade to another build. Version 9.1.2 had UCI problems that are fixed in 9.3.1 so I'm not keen to go back to 9.1.2 if I can avoid it.

As an update, QSC confirmed the bug with amplifiers displaying offline on their front panels and resolved it with QDS 9.5.0.

[Jason Raftery]

Did you also change the IP address and netmask back to what it was? Without that, it will auto IP itself with a 169.254.X.X address, and the core won't be able to see it to push the design into it.

Are others not using dynamic pairing to avoid this? So long as the QLAN switch is in a secured area, tying each component to a specific port on the switch gets around the 169.254.x.y IP address issue and makes it much easier to talk someone on site through replacing a device when one fails. No need to configure anything on the replacement device so long as it is the same model as the outgoing one and is plugged into the same port on the switch--the core does it all.

[Jason Raftery]

Is anyone using the DCIO-H in a professional Cinema? We have a Barco SP4K feeding the DCIO via AES and an HDMI output of an NV-32 into the same DCIO. I'm wondering what the experiences are from other users. We had been experiencing frequent random audio dropouts from apparent Package loss events using the HDMI input and I witnessed one isolated issue from a DCP playback. 2 days ago the DCIO went offline and now won't load or be recognized in the design. The DCIO is the only component that is exhibiting the Packet loss issue.

I haven't used the DCIO-H and am not yet running QDS 9.6, but in addition to the advice others have offered, try rebooting the core itself when able if you have not already done so. In older QDS versions, I've run into situations where a device can go offline and the problem was with the software on core, not the endpoint device. Rebooting the core would then trigger the device to load the design and pop back online.

[Steve Guttag]

Unless the settings on the switch were changed in the middle of the show during which the DCIO-H borked, I'm struggling to understand how bad switch settings could have caused this. Bad packets ever since the original install, yes, but all these problems suddenly appearing with just one device on the Q-LAN, and after many months of trouble-free operation?

Because you get clock drift that will cause a collapse, at some point. When it comes to IGMP...if the device becomes undiscoverable, you lose the device until it is found.

Is anyone else having significant problems with QDS version 9.3.1?

I don't recall any specific problems with 9.3.1 but it wasn't one that I hung out at. 8.4.0 was a safe QDS version that I hung out at for a long time. 9.0 - 9.4.2 didn't play nice with the IMS3000 (running Atmos). When the IMS3000 woke up and took over the GM clock, you had a 10% chance it would lock up a CORE 110. 9.1.x changed the security of QDS and the devices on it. Since when has security made things run better? However, once QDS 9.4.3 LTS came out, I was on board. Everything started to just work on that version of 9. I have not had issues on 9.4.4 LTS either. I had two sites on 9.4.5 LTS. The first site has run without issue and, in fact, ran for weeks without issue. I loaded into my next site and within 3 days the CORE 110 rebooted itself on 2 consecutive days. I backed that second site down to 9.4.4 LTS and the problem vanished with it. Note, both sites used CORE 110s so there is nothing different there. The designs are different so there may be an interaction with one and perhaps a memory leak that manifests in the core rebooting itself. I have a ticket open with Q-SYS on that one so we are still working through it.

QDS 9.4.5 LTS has the amplifier fix in it.

REALLY suggest moving to the LTS branch of QDS and avoid the cutting edge ones. Unless you are getting specific features out of 9.5 - 9.8, move to 9.4 LTS. The LTS branches get all of the bug fixes without all of the new features that create all of the bugs.

Dynamic Pairing

I have, thus far, opted to not set up dynamic pairing. The benefits, in my applications, do not outweigh the time it takes to set it up and the advantages to having a fixed IP scheme (though one could pre-IP a spare amplifier or DCIO-H or whatever for a dynamic pairing system. Thus far, I have remote-in capability in just about all of my Q-SYS systems. So, if the client can do the amp swap (or whatever), I can take over from there to get it into the design. Total time spent will be FAR less than configuring the dynamic pairing on all ports for all theatres. Now, since you list that you have 4.3 and 4.5 amplifiers (known for their less than reliable nature) perhaps it isn't such a bad idea. There is nothing wrong with setting up dynamic pairing, however. It could make a customer swap a lot easier.

In my high-brow theatres and just about all of my Atmos rooms, I put a spare center or center/subwoofer amplifier in the rack such that all one has to do is move the speaker wire Phoenix plug to the spare and they are back up. That is in addition to providing for a bypass signal path that can be activated on the fly if any of the screen speakers go off line.

Back on topic. Seriously, getting QoS set up right on the switch (and having it match the parameters in QDS) is critical and setting up IGMP will go a long way to eliminating "missing" devices. It is to the point where it NEVER (and I'm serious NEVER) happens to me. The only time I see packet issues it comes back to the patch cable...reseat it and the problem evaporates. And those are incredibly rare too. I don't use high-brow network switches (TP-Link...currently the TL-SG2428P and the TL-SG2210MP). I also don't allow ANYTHING on QLAN-A that isn't Q-SYS or working with audio streams, like the IMS3000.

The fault tolerance in cinema is incredibly low compared to other industries. A little audio glitch, not noticed by anyone, in A/V won't fly in cinema where everyone notices the slightest audio glitch. As such, I guard the Q-LANs and almost always run dual networks. It is incredibly cheap insurance to an audio problem. For CORE 110s (just two NICs), I use QLAN-B also as the control network...BUT I send it through a router to the normal LAN/Management/control network. However, normally, when I have multi-screens, then I'm on larger cores like the 510 or, now the 610 so there are separate NICs (AUX) for control...which lets the QLAN but just audio and incredibly stable.