Q-SYS Corner

[Steve Guttag]

I should point out, I've updated the Taillight component, thanks to Ioannis Syrogiannis for pointing a bug in the original.

Updated ones attached:

Barco S4 Taillight Only 231012.quc.zip
Barco S4 with Taillight 231012.quc.zip

Screen Shot 2023-10-15 at 11.07.58 AM.png

Screen Shot 2023-10-15 at 11.07.23 AM.png

[Steve Guttag]

QSC has released two updates. For the cutting edge (more risky but required for the CORE 610)...QDS 9.9.1. And, for the rest of us, the Long Term Support version 9.4.6 LTS.

9.4.6 LTS

Platform

Default NTP servers updated to match NTP.org
Disabled HTTP OPTIONS for peripherals
Q-SYS Remote Control Protocol (QRC) adds client IP addresses to messages


Resolved Known Issues

• Audio: Addressed an issue that would cause a "Compile Failed" error when deploying a design with an NL-C4 and/or NL-P4 speaker.
• Audio: Resolved an issue where the GPIO Input state remained false at deployment for Digital Input and Contact Closure configurations.
• Amplifiers: An issue that would show inaccurate time constants on an RMS limiter has been resolved.
• Amplifiers: Addressed an issue where CX-Q Power Meters would only show two meters, effectively hiding the Output (dBFS) meter.
• Amplifiers: Addressed an issue that would cause an 8-channel CXD-Q, CX-Q, and DPA-Q to show an error “Compromised - High CPU Usage".
• Loudspeakers: Updating a loudspeaker component's Model to AD-P.SUB in the schematic no longer causes an error.
• Video: Addressed an issue that would cause an NV-32-H Encoder to send unicast audio when it should be sending multicast audio.
• Video: Resolved the issue causing NC cameras to enter a boot loop.
• Video: The Dynamic Idle Screen is no longer automatically loaded if it is turned off in Q-SYS Core Manager.
• Control: An issue that could cause SNMP read values to truncate over 100 characters has been resolved.
• Control: Addressed an issue that would cause SNMP polling to stop after changing a Target Agent IP in QDS.
• Control: Resolved the issue that would cause the Core to constantly restart when using an SNMP Script.
• Control: Sending a message via SNMP Script to an IP that does not exist now sends back a timeout to the Error Event Handler.
• Control: Resolved an issue that would cause erratic Core behavior (slow performance, other processes stop, SNMP polling stops, etc.) when using certain SNMP scripts.
• Platform: QIO, NL, and NM series peripherals now report 802.1x port authentication status in Peripheral Manager.
• Platform: An issue that could cause all input sources to play through a Virtual Page Station message has been resolved.
• Platform: Addressed an issue where enabling NTP Time Synchronization on a Core would temporarily open Port 123.
• Platform: An issue that would cause NodeJS log errors has been resolved.
• Platform: An issue that caused QIO, NL, and NM Series devices to not work with Cisco ISE has been resolved.
• Platform: The issue with how Core MAC lookup was inaccurately managed on L3 networks for QIO, NL, and NM Series devices has been resolved.
• Platform: Addressed an issue that would cause the QRC port to be inaccessible after a Primary Core failover.
• Platform: Addressed an issue that could cause the serial port on an I/O-22 to stop functioning.
• Platform: An issue that would allow unauthorized read/write access without authentication on a Redundant Core using rsync has been resolved.
• Management: Resolved an issue that would cause Event Logs Date and Time to show invalid in Core Manager.

[Steve Guttag]

I have discovered a bug in 9.4.6 LTS, unfortunately. It affects Custom Speaker Voicing components. The HPF and LPF state may be ignored by QDS and not respect the crossover settings. Naturally, this could damage speaker (diaphragms getting wideband signal). Toggling the bypass buttons on the respective filters will cause it work but that is not practical. I have reported it to QSYS. For now, I'm recommending QDS 9.4.5 LTS as the best-most-stable version. If you do not use Custom Speaker Voicing components, then this bug will not affect you. It does not seem to affect the intrinsic correction components, as supplied, for QSC speakers.

A possible work around is to use crossover components in your design but that sort of takes away a big advantage of the Custom Voicing component in that you create it once and it works for every speaker of that make/model.

I, first, discovered the problem (and reported it to QSYS) in version 9.9.0 and it remains in 9.9.1 so going to one of them is not a help. I've never had an issue in 9.4.5 LTS

[Leo Enticknap]

I just came across a quirk that I thought would be worth flagging up here, as I lost a couple of hours figuring it out.

If a control name within a block controller component has a space in it, that control cannot be called from another block controller script. If it is, that script will report an error and stop running. You can call it from the script in the same block controller component as the control itself, but not from an external one.

In the original version of the script, the highlighted controls originally had spaces where you see the underscores:

image.png

When it ran, the block script crashed with an error message as soon as it hit the first "set named component" that referenced another block controller component. But controls within the same component with a space in their names (above the first external one) worked OK. Changing all the spaces to underscores fixed it.

Sorry - can't remember what the wording of the error message is, and don't want to deliberately break a component again to emulate it.

[Steve Guttag]

Leo, thanks for posting! Naturally, I don't know just what your block is doing but I can guess based on the name of things that it is monitoring what format is selected and updates the UCI and the signal flow. Going back forever and a day, it has always been standard practice to avoid spaces as they can be, legitimately, interpreted in multiple ways (the end of an expression or argument, for example) and the underscore is the most common means of putting a space in a name. Often there is an escape character that will allow one to keep the space (e.g. preceding it with a percent symbol or in quotes or a backslash with a blessed letter...much the same as a carriage return \r.

Some ASCII commands, particularly queries will take the form of "command=?" and that equals and the question mark can be interpreted multiple ways. Or when sniffing for the various formats in a DCI name...there are hyphens which can be an algebraic expression. The question mark is in the "magical characters" group and needs a % in front of it (%?).

You might find it informative to look at your original block control in LUA view to see how it got translated and it might let you see how it was interpreting the spaces.

From the LUA manual:

Lua is a free-form language. It ignores spaces (including new lines)

Though you might not be using LUA directly, that is what is running under-the-hood. So, all of its rules still apply. I'm wondering if %s wouldn't let you "look" for the space character in the string. Clearly, I'm not a LUA coder and lean heavily on the Block Controller. Since this is a named control, I'd think there would be a means for Block Controller to handle the overhead...it is probably worth reporting to QSYS, if you haven't done so already.

[Marcel Birgelen]

@Leo

I guess you checked if the Script Access on the referenced named component was All or External? If so, this clearly seems to be a bug to me.

According to Q-SYS's own training material, named components can have spaces. In LUA those components are referenced via the Component.New("component name") function, which can in turn be assigned to a variable, which does need to be free from spaces.

[Chris Horak]

Has anyone been successful in getting a Q-SYS Core to transmit AES67 to Dolby's DMAs?

The DMA seems to expect all streams to belong to the same multicast group (address) and it identifies which streams (group of 8 channels) packets belong to by checking their unique source port and SHARED destination port.

I set up AES67 transmitters in Q-SYS, but Q-SYS throws an error saying that each transmitter should use different multicast addresses, and furthermore doesn't allow you configure the source port. I did some packet analysis and it seems the system picks an unused port at random for the source port. Even if I could figure out the source port for each stream reliably for the DMA, how could I get around the DMA expecting the multicast group to be the same for all streams?

[Steve Guttag]

Chris,

The answer is yes, I have done it with a 24 and a 32 channel DMA in an Atmos application. The examples below are running in QDS 9.4.5 LTS so what you see may vary based on the QDS you are using.

To be clear, this system has an IMS3000 being used as the Atmos processor and is the GM clock for PTPv2. The content comes in via standard Atmos receivers without any special configuration beyond I use the PTP domain number is 100+Theatre Number to ensure if there are multiple Atmos systems, they all have unique domains. The DMAs are only used for surrounds (all surrounds so they are used for non DCP content as well...hence they need to be fed from QSYS. There is a method where a source like the IMS3000 can feed the DMA's directly and only use QSYS for other channels. That is not the case in my example set up.

• Each transmitter (I have 7 in this design) is given a unique/descriptive name with 8-channels and the connection mode is left in "Auto."
• Once the design is running, within each AES67 transmitter, is given a unique Stream Name and Multicast Address (within the acceptable range...that is in the QSYS Help file for the acceptable range, including if one is interacting with Dante).

Screen Shot 2024-01-20 at 2.39.43 PM.png

I'm overlaying the first two transmitters below

Screen Shot 2024-01-20 at 2.43.53 PM.png

Now, on the Dolby DMA side, go to "Input". You are going to want to untick the "manual mode" box. Put in the PTP Domain number (for me it would be 102 in this example though a bug in Dolby's software, it will show "0" but will be correct in the logs. You have a set of drop-downs where you can select which AES67 stream you want to assign to which group of channels. Note, it can take a few minutes after things are configured before the DMA will "find" the streams...so be patient. Once assigned, it will find them again, including on subsequent power cycles.


Screen Shot 2024-01-20 at 2.51.40 PM.png

Note it is the Stream Name that it finds.

Then, in Routing, you assign the stream channels to the amplifier channels as normal for a DMA. In my case, it is 1:1 though I bridged the channels for LW1 and RW1 in the example below since it needed more than 300W:

Screen Shot 2024-01-20 at 2.53.55 PM.png

[Chris Horak]

Hi Steve,

Thanks a bunch, this works!

The combination of using "auto" and disabling IGMP snooping allows the DMA to subscribe to AES67 streams from Q-SYS.

Pretty surprised by this, it would seem "auto" and "manual" do not have feature parity.

[Steve Guttag]

Yeah, on all Dolby products, one has to turn off IGMP snooping (on the switches I use, I set things Dolby are plugged into as "Static Router" ports. I leave IGMP snooping on for all other ports as that can help QSYS native peripherals be discovered properly (particularly touchpanels). It's a game we must play, it would appear.

[Steve Guttag]

FYI:

The CORE 510i and its associated cards are now back and off of "EOL." So, if you are still using DCA amplifiers and want a core that can connect up with Dataports, the CORE 510i could be the solution. The CORE 510i is also lower cost than the CORE 610 in both the cost of the unit itself as well as the various licenses associated with it. So, if you don't need the CORE 610, the 510i can be a lower cost alternative. IT can also be used in peripheral mode to allow for its use of the I/O cards (including Dante) on a larger or more complex system.

[Steve Guttag]

QDS 9.10.0 has been released. While it does add new features (or recognizes new equipment that is part of the QSYS family), it is mostly a collection of bug fixes. Of particular interest is that the Custom Voicing Block should always honor the crossover settings. As always, I recommend the LTS branch of QDS and, until they fix the Custom Voicing in the LTS branch, that would be 9.4.5 LTS. But, if you are using the CORE 610 or perhaps a new peripheral (some of the QIO or NV), 9.10.0 should be a more stable QDS than 9.9.

What's New in 9.10

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

New Product Support
QIO-AES8x8
QIO-TEL2
Microsoft Teams Rooms UC Integration License
PL Series Performance Loudspeakers for Q-SYS
AcousticDesign Series: Zero Bezel Loudspeakers

Platform
Improvements to QIO, NL, and NM Series devices Status component
Core Manager: HTTP has been disabled Audio

QIO Devices: Quiet Mode
SPA-Q component control for "Mute All"

Video
NV-21-HU: Dual Streaming

Control
Q-SYS Control for Microsoft Teams Room (MTR)
Background CSS Properties
Periodic Auto-Save
Monitoring Proxy updates
Control Panel Pages in Script Components
UCI Toolbox
Lua WebSocket Ping/Pong protocol
Scripting Components: 'Start Automatically' Property

Management
Core Manager and Enterprise Manager: Inventory Columns
Enable more robust passwords for users accessing Q-SYS Cores through Q-SYS Core Manager
Core Manager: QSD Authentication

Resolved Known Issues

• Audio: The issue of QIO, NL, and NM Series devices showing “Fault - LAN A Streaming Error (Packet Missing)” when trying to sync to an external PTP clock announcing a non-zero originCurrentUTCOffset value has been resolved.
• Audio: An issue causing the NL-SB42 speaker health monitor to falsely report in Open Circuit has been resolved.
• Audio: The issue that would cause Softphone audio to not transmit out to RTP streams on Core 610 has been resolved.
• Amplifiers: An issue that caused Custom Voicing in High and Low Pass Filters to be bypassed incorrectly has been resolved.
• Video: USB compile check now accurately flags the endpoint count issue on NV-21-HU.
• Video: The intermittent USB connection issue when using an NV-21-HU USB-C to USB-C cable for USB Bridging has been resolved.
• Video: USB HID routing no longer experiences issues if designs contain both USB Audio Bridge Output and USB Video Bridge.
• Video: Resolved an issue where NV-32-H Decoder encounters an error “Fault- Not Receiving video from <encoder name>”.
• Video: NV-21-HU now correctly displays 'Non-HDCP Source' in HDCP Status with USB-C connection.
• Video: An issue that caused NV-32-H and NV-21-HU to show a green video on Encoder start up has been resolved.
• Video: NV-21-HU firmware update now completes promptly without prolonged 'Reboot initializing' status.
• Video: The issue that would cause a temporary flicker, black screen, or color change on an NV-32-H configured as a Decoder with dual HDMI outputs has been resolved.
• Control: An issue that would force Control feedback to stop working on Q-SYS Control for MTR has been resolved.
• Control: Resolved an issue where malformed CSS style sheet documents may cause Q-SYS Designer to unexpectedly close.
• Control: Resolved the issue were assigning values to a list box control may cause an event handler to fire when the script first runs.
• Control: MTR components configured with hostname connection no longer enter a fault state due to IP address changes during automatic nightly reboots.
• Control: After updating to Windows 11, accessing 'Room Controls' on the touch panel no longer leads to a black screen and unresponsive controls.
• Control: Connecting to a WebSocket server by name no longer causes script blockage during the connection phase.
• Platform: In version 9.9 and running on a Core 610, the Gating Automatic Mic Mixer’s NOM Gain was fixed at 0dB. This has been corrected. The NOM Gain now again depends on the number of open microphones (NOM).
• Platform: An issue that would allow unauthorized read/write access without authentication on a Redundant Core using rsync has been resolved.
• Platform: The issue that caused the error "Design Exceeds the Memory Capability of the Core" has been resolved.
• Platform: An issue that would cause Signal Tags to give an error 'Already in Use' within Containers has been resolved.
• Platform: Mic Impedance not working on a Core 110f while in Peripheral Mode has been resolved.
• Platform: QIO, NL, and NM Series devices no longer show "Missing in use by another design" when deploying a design.
• Platform: Addressed an issue that would cause the QRC port to be inaccessible after a Primary Core failover.
• Platform: The network flooding issue caused by random packet addresses has been resolved.
• Platform: An issue causing a Core to stop running while using the Automatic Camera Preset Recall has been resolved.
• Platform: You will no longer see any errors when assigning Signal Tags within a Container.
• Platform: The issue of distorted audio from an External USB device has been resolved.
• Platform: When adjusting the Network Tx Buffer from none to 5ms in an AES67 Transmitter appropriately increases by 5 ms.
• Platform: The issue with the Inspector not showing the scripting engine requirement and the absence of the yellow license section in the menu bar has been resolved.
• Platform: The issue of not being able to add a signal tag to a connection between a component with audio outputs and a signal snake has been resolved.
• Platform: An issue with the Standard Delay component's distance control not being able to be set to zero has been resolved.
• Platform: The component selection issue, where the "View Component Controls" menu didn't show details of the selected component, has been resolved. The details appear immediately upon selection.
• Platform: The issue of the Virtual Page station not being able to be wired from inside a Container, despite the pin changing according to connection type, has been successfully resolved.
• Platform: The issue where the Tx Flows in the Software Dante Blocks remained at "0/4" has been successfully resolved. The Tx Flows accurately reflect the active multicast flows.
• Platform: An issue where the Status Block cannot be found in a Design has been resolved.
• Platform: The issue where Microsoft Teams License Bundle appeared as Other License Type has been resolved.
• Platform: Addressed an issue that would prevent designs from starting if Software Dante had run out of file handles.

[Steve Guttag]

Following up on post 263 above (Dolby DMA amplifier).

I've found that the Dolby DMA amplifier is weak on its AES67 implementation and that it can lose clock-lock and or streams...seemingly at random. It isn't super-common but too common for my liking. It, normally, self-recovers but while a stream is missing, 8 speakers won't be playing. If the amp loses the clock, then all channels from that amplifier will be dead until it returns. Losing the clock is more rare but if you toggle any stream feeding that amp, there is a better than 50% chance that the amp will lose sync with the clock for a second or two.

I'm working on a QSYS component to try and improve the system's ability to monitor this and force the DMA to reacquire the stream/clock (toggling the affected stream always seems to bring it back. Toggling all streams always seems to bring a clock sync back (though they almost always self-heal).

The component, at the moment, is looking like this:

Screen Shot 2024-03-03 at 10.42.45 AM.png

The component will monifor if the amplifiers are off (obviously, if the amplifier is off, all of the streams will also not work). Upon the Amps On status going true, the module will count down (about 4:30 for the 32-channel amp...I've noticed that the 24-channel coms up about 45-seconds faster). Once it is up, it will read out the line voltage and current for the amplifier (don't get too excited, the SNMP information is truncated to the nearest volt/amp...so it shows 1 amp almost the entire time...not 1.x...it truncates to the whole amp). It will then keep count of the number of times a stream or clock bobbles (goes away and comes back quickly so no need to try and get it back) as well as keeping track of how many times it had to reset a stream and also marking the date/time it last had to do that.

The status switches to Initializing with a countdown while booting up:

Screen Shot 2024-03-03 at 10.53.48 AM.png

And once it is up:

Screen Shot 2024-03-03 at 10.57.55 AM.png

Naturally, this are not customer facing components. I am, however, sending the status to a Status Combiner so that on the Main page of the UCI (touchpanel or web page) it is part of all of the other status displays. If either a clock or stream is lost, the status will update to "Compromised" (orange) (with the stream number identified) if it is a stream and "Fault" (red) if a clock is lost.

So my question to other people out there using QSYS with the Dolby DMA...have you come across this problem? Key elements that may affect my installation is that the clock source is, ultimately, the IMS3000 since it is an Atmos house. If the Core was the clock source, this may not have been an issue. The DMA is fed via QSYS AES67 transmitters so, as I interpret it, the IMS3000 starts it...then QSYS has to relay that via the transmitters to the DMAs. Monitoring the clock drift via the Core status...it is almost always between +/- 1usec and is at 0 most of the time. Transitioning between content, the server starting a show...etc. does not seem to cause the issue. I've run short shows (5-seconds) on a loop and it handled it...I looped a sequence of cpls with different sound...some with Atmos, some not and while you can see the Atmos receivers react to the change, it did not induce an issue on the DMA. There are two DMAs in this system and there isn't a correlation (when one drops the clock, it does not mean that the other will). Same comment on stream drops. In fact, I found one had a stream issue at 2am when no movies had run for hours. Now, I have seen where content changes within the show has coincided with a bobble on a stream or clock but it isn't like it is repeatable. So, it is nearly impossible (thus far) to track down a cause/effect via the show.

So Chris, have you run into this issue?

[Steve Guttag]

QDS 9.10.1 has been released. It is a relatively minor bug-fix release that likely does not pertain much to cinemas (unless you are doing work with Zoom calls and related activities with Q-SYS). Still no update on the LTS branch for fixing the broken Custom Voicing Blocks in 9.4.6 LTS...I still recommend 9.4.5 LTS:

v9.10.1


Version 9.10.1 was released March 21, 2024. It is a patch release required for supporting the Q-SYS Control for the Zoom Rooms App. This app is available for download via the Zoom Apps marketplace. For more information on configuring and setting up this app, refer to the Q-SYS Knowledge Base > Zoom page.

Resolved Known Issues

• Video: An issue that would cause cameras to stop streaming when Auto Framing was enabled has been resolved.
• Platform: The issue of delayed Core availability status in QDS v9.10, where Cores appeared as "Contacting" for an extended period compared to immediate availability, has been resolved.

[Leo Enticknap]

I've hit an annoying issue with the Netgear AV switch plugin. With it running, I get a red "Server Error - 500" once during every polling interval (which I currently have set to 10 seconds). It flashes for about a second, before the status returns to OK; rinse and repeat.

image.png

In all other respects the system works without any problems: 4K HDMI between the Q-Sys video endpoints is totally glitch free. But it would be nice to be able to get rid of the false red alerts. I've had a look around online, and this seems to be a known issue with some Netgear switches, though I can't find anything related to the Q-Sys plugin specifically. If anyone knows of a quick and easy tweak, any suggestions would be gratefully appreciated.