Q-SYS Corner

[Tj Hopland]

I just did a project with a 24f. Design work was done thinking it was going to be a 110f. Didn't really notice any quirks changing to the 24f. When you do change the core itself in an existing design anything that was 'attached' to it disappears. Make sure you at least take mental notes of features you were using so you can bring those back into the design and re connect them. Your main ins and outs are not bad but some of the lesser used features can be harder to remember.

Kinda of along these lines does anyone know if there is a feature in designer to 'find' things sort of like you do on a PDF? Like where you could highlight say the core and it would then take you to the various pages and places in the design that are using those components? Could also be a handy tool for working on a UCI to find or be reminded where a specific control actually came from. You could highlight a gain control in the UCI and it would take you to the amp it was attached to. My designs are not that complicated so its not that hard to figure out but I recently had to mod a 7 year old design so it took some time to figure out what my mindset was back then. Hate to think about a large design like say an international airport or large convention center sort of thing.

[Steve Guttag]

I don't know of a find that finds the various parts of a Core (e.g. the input component). Now, there is a CTL-F find command that I use all of the time to find where wire tags are but that wouldn't, necessarily help with finding a missing component so you can bring it back.

One would presume that you still have a copy of the schematic before making the change so you can compare. It does make the argument to use wire snakes instead of wiring directly to the Core or just locating all of the Core's inputs/outputs in one location.

To a degree, this is like the exercise I went though showing how to replicate auditoriums on the Sample 7.1 design (needing to add in a DCIO and then put its bits and pieces over the design.

[Steve Guttag]

MIT has acquired the cinema speakers from QSC/Q-SYS. So as to not repeat a post, here is a link to my Film-Yak post:

https://www.film-tech.com/vbb/forum/...-sys#post54121

[Steve Guttag]

Whelp...QDS 10.1 is here. Key things that jump out at me, with respect to Cinema (there are tons in there for people doing Zoom/Team rooms) are the change from Asset Manager to Library for plugins. I big one to keep an eye on is that there has been a hardware revision of the TSC-50-G3 that is expected to hit distribution around March of 2026. The new (internal) hardware will require QDS 10.1!!!

I'll probably do another post about it but here are the bullet points from the QDS help file:

v10.1.0


Version 10.1.0 was released November 20, 2025, and includes these updates and resolved issues.

New Product Support

NC-90-G2 Network ePTZ camera
NC-Pro15x Network ePTZ camera
QIO Series High-Density Audio Expanders

Platform

Q-SYS Library
Batch-Add Inventory Items
Platform-Level Horizontal Scrolling

Audio, Video, Control

Single-Button Remote Zone Groups Paging
Improved SDP Compliance for ST 2100
ST-2110 Audio Control Flexibility
NMOS Network Configuration Enhancements
Face Focus for NC Series PTZ Cameras
Text Controller Enhancements
TSC-50-G3 Touch Screen Compatibility

Management

Secure Communication Interface Reorganization
Clearing of Core Manager Event Log for Admins Only
Enhanced Security Management Options for Administrators

[Steve Guttag]

Resolved Known Issues

• Audio:Resolved issue where audio routed to output 2 and NV-32-H would also play through output 1 on the first playback after a design restart or core reboot.
• Audio: Resolved the issue where CX-Q amplifiers fail to reapply loudspeaker Intrinsic Correction™ IIR filtering after exiting standby mode for some speaker types. Affected loudspeakers included: AD-C8T-ZB; AD-C10T-HPZB; PL-CA5/6/8/12/15/; PL-DC8/12/24/26; PL-LA8/12;PL-SUB10/12/15/18.
• Control: Resolved an issue that prevented plugin and user component files from installing on double-click.
• Control:Resolved an issue where autosaved Debug Output files contain extra Hex that isn't in the script's Debug Output.
• Control;:Resolved issue where shared layers do not appear in the block controller's command code, affecting visibility control in the UI.
• Control:Resolved an issue where audio files did not populate in the administrator commands interface.
• Control:Resolved an issue where media previews within a UCI scaled improperly and had distorted aspect ratios when switching from 1fps jpg to 30fps.
• Control: Resolved an issue where Lua's bitstring.unpack() failed to decode 32-bit floats correctly on hardware cores, despite working in emulation mode.
• Control: Resolved an issue that caused control names to revert to their original names after being renamed, requiring deletion and re-adding controls to reuse names.
• Control:Resolved an issue with the UCI script window becoming un-editable after being undocked and re-accessed.
• Control:Resolved issue when opening a Design created in a version of Designer before v9.0 in v10.0 does not prompt the user of the required v9.0 migration step.
• Control: Resolved an issue where extensions/plugins generated a runtime error when special characters were included in the file location names.
• Control: Resolved performance issues with the Room Control UCI, related to sluggishness caused by pop-ups and complex layers.
• Control: Resolved an issue found in Q-SYS Designer, when emulating, Network.Interfaces() returns empty address strings instead of the expected IP addresses; affects scripts that rely on enumerating NIC IP addresses during emulation.
• Control: Resolved performance issues with Zoom app UCI responsiveness on Poly TC8 and Logi Tap IP devices, where certain firmware and Zoom Rooms versions cause significant sluggishness, with performance varying across devices.
• Control: Resolved an issue where learned IR commands were not retained when an "IR Receiver" component was copied and pasted within a design or between designs in Q-SYS Designer, forcing users to relearn IR commands for each new instance of the device, in their design.
• ControlResolved an issue related to the Text Controller where disabling the "Start Automatically" option caused the old code to be displayed during runtime.
• ControlResolved an issue where CSS icons/images were not rendering in UCI viewer when button style was set as Image.
• Platform: Resolved Remote Destinations do not show up as directly selectable zones in the Virtual Page Station.
• Platform: Resolved the issue where the Multi Add Inventory Name field did not enforce hostname validation rules, including a 63-character limit and restrictions on invalid characters and formatting.
• Platform: Resolved an issue where all 8 Mic/Line inputs on Core24f could exhibit incorrect audio levels after a design load.
• Platform: Resolved an issue where the ST-2110 Transmitter displayed an incorrect reference clock address—not matching the Grandmaster clock—in the SDP details tab.
• Platform: Resolved an issue where the NV-32-H (Core Mode) did not display the required Dante license error when saving a design to the core.
• Platform: Resolved an issue where the Slot A Block was not removed when switching from Core 510i to Core X10 in Q-SYS Designer.
• Platform: Resolved an issue where the Core 8 Flex could lose GPS clock synchronization when connected to Pin-1 of the GPIO, with a GPS (5PPS) clock type and a 5 HZ GPIO signal.
• Platform: Resolved an issue when copying a container with grouped items to a new blank design, caused a duplicate key error.
• Platform: Resolved an issue where the Notch Feedback Controller RTA display was incorrect above 450 Hz, showing a straight diagonal line instead of the actual audio signal.
• Platform: Menu shortcuts now display properly irrespective of the OS language.
• Platform: Resolved a router issue where "Selection Controls" property was incorrectly forced to a non-crosspoint mode when exceeding total control maximum by correctly enforcing control limits.
• Platform: Resolved an issue where using a reserved name resulted in a compile error by blocking the use of reserved names.
• Platform: Resolved an issue where the names of pins in a container could not be directly edited.
• Platform: Resolved an issue where cameras attached to Mediacast Router inputs did not consistently toggle out of privacy mode after a design push.
• Platform: Resolved issue where Core 24f designs that were close to using 100% of the Core’s signal processing resources failed to run reliably.
• Platform: Resolved an issue where prolonged operation could cause cameras and system components to enter a failed or initializing state due to a race condition and memory leaks.
• Platform: Resolved issue where UCI viewers using port 1700 will not connect on Core AUX ports, blocking users from using UCI Viewer on AUX networks.
• Platform: Resolved a Q-SYS Designer issue where the calculation of permitted AEC channels is locked at 8, regardless of tail length, leading to incorrect license requirements.
• Platform:Resolved an issue in Q-SYS Designer where Server Core X10 and X20 models failed to allow peripheral counts above 256, causing a compile error instead of a warning and compiling.
• Platform:Resolved an issue where adding a standard delay inside a Channel Group caused the configuration units drop-down to become blank and un-editable.
• Platform:Resolved an issue where activating an Entitlement ID containing licenses such as Dante 32x32 incorrectly placed valid licenses in the ‘Non-Applicable’ section.
• Platform:Resolved an issue where the Q-SYS Administrator displayed the version number as "1.0.0" instead of "10.0".
• Platform:Resolved an issue where the log file system grew to consume all available space, causing issues with message rotation and core crashes.
• Platform:Resolved an issue where selecting "Touch Screens" in the Inventory filter option removed G3 Touch Screen panels from the Inventory list.
• Platform:Resolved the issue of CDN64 Dante Cards intermittently unsubscribing their channels automatically without manual intervention.
• Video:Resolved issue related to exposure changes in 20x NC cameras after a software update to version 10.0, which caused images to darken and required gain adjustments.
• Video:Resolved an issue where AV stream switching caused intermittent video noise on dual outputs. The problem was linked to the AV stream router, which introduced abnormal bitrate settings and eventually distorted video, but did not occur when the router was removed.
• Video:Resolved an unstable connection issue on the NV-21HU when plugging into the USB-C port.
• Video:Resolved an issue where Encoder stops sending stream during specific PPT and video streaming situations.
• Video:Resolved intermittent issues with NV-1 units going missing after a few hours of operation, despite functioning correctly during use.
• VideoResolved issue with long enumeration times when bridging devices via USB-C on a Dell Latitude 5440.
• VideoResolved issue with USB-C video and USB connectivity on a Dell Latitude 5420, which experienced intermittent connection resets with delays over 30 seconds for video and USB bridging to appear on the laptop, caused by NV21 connection resets.
• Video: Resolved an issue where a Dell Latitude 7330 laptop failed to output video over USB-C, despite the display being detected and USB bridging working initially.
• Video: Resolved an issue on Dell Latitude 5420 laptops where video and USB bridging were delayed by over 30 seconds when using a specific USB-C connection during testing with version 10.0.0.2505.002.
• Video: Resolved an issue on Dell Latitude 7330 laptops where no video output was available over USB-C despite USB bridging functioning correctly.
• Video: Resolved an issue on Dell Latitude 7330 laptops where USB-C connectivity failed, resulting in no video output and no USB bridging, with HPD trigger and USB reset attempts unable to resolve the problem.
• Video: Resolved HDCP-related streaming errors and packet loss on NV-21 encoder LAN A when handling 4K60 sources with HDCP 2.2 encryption.
• Video: Resolved an issue where NC cameras went offline when disabling privacy.
• Video: An issue where two NV21 decoders experienced an internal audio stream error has been resolved.
• Video: Video: Resolved an issue where NV21 encoder mutes audio when transmitting non-PCM formats.
• Video: Accommodated for MacOS dithering, resolving an issue that was causing high bitrates, packet loss, and errors in NV products.
• Video:Resolved an encoder stall issue where streams stopped unexpectedly.
• Video:Resolved an issue where the I/O-USB Bridge and other video bridging peripherals were not functioning with Zoom Room camera presets.

[Steve Guttag]

Q-SYS For Cinema
Blog-25 Q-SYS Networking for Cinema
_12/5/25

Current QDS Versions: 10.1.0 and 9.13.1 LTS
Introduction

Networking. It strikes fear in some and frustration for (some) others. For many, it is no big deal. As cinema people, we all deal with networking, at some level, just for conventional projection and sound within the Digital Cinema world.

Let me get this out front and early. I am not a networking professional. That is, have no formal training or certifications (beyond Q-SYS’ Networking training course, which you too should avail yourselves) and the mentoring from some very kind people.

So, if you know what you are doing or if you have people within your organization that know what they are doing with networking, please, follow their guidance. What I am going to present is from a seat-of-my-pants, self-taught, perspective and my interpretations of what I have read in Q-SYS documents plus Q-SYS training. With that in mind, this particularly blog entry is, mostly, for the person that just doesn’t know where to begin with a Q-SYS network. Please don’t be too put off by this blog’s length. There are a fair number of images/topologies to try and add some clarity to the words.

For most Q-SYS cinema installations, we do not need as much from networking as many “A/V” type installations since we are mostly just handling sound and control, without much in the way of video (but we shouldn’t exclude video as Zoom/Team room type infrastructure can help cinemas more-fully utilize their spaces). This allows us to utilize some more cost-effective networking infrastructure and I will present ones that have worked for me (in the Appendix). Truthfully, the Q-SYS network isn’t all that complicated so don’t feel that it is very hard to implement.

Disclosure

I do not, in any way, work for QSC/Q-SYS. These thoughts are my own based on my own interactions with the product(s) and implementing Q-SYS within actual cinema environments. I do work for a dealer that has sold QSC products since the 1980s, including Q-SYS and its predecessors. For the purposes of this blog, I represent only myself and not my employer(s) or any other company.

Digital Cinema Networking

Most Digital Cinema installations consist of two networks. One for “Management” that has control communication. We will likely want connectivity to that network so that Q-SYS can be told what sound to process and what volume level to set. Additionally, Q-SYS is likely going to both control and monitor booth equipment. Connectivity to that network would be essential for those purposes too.
The other network, typically, is the Media network for content transfers. In general, Q-SYS does not need access to that network.

QLANs

In Q-SYS, at the very minimum, you will need to have one QLAN, unless you just use a Core, like the Core 24f, and only use analog inputs/outputs to traditional analog amplifiers. For most every other scenario, you will need to create a QLAN.

What is a QLAN?

A QLAN utilizes conventional networking infrastructure (CAT5e/CAT6 cabling with 1G or better network switches) to transport audio, control and video. It is all the same type of equipment you are already using but with some minimum requirements on the network switches to ensure that data on the QLAN network doesn’t run into timing issues.
The big ones are:

• You need 1G port speeds, minimum (you’d almost have to try to find something slower now).
• The bandwidth of the switch has to be able to support your worst-case scenario. If you are just handling audio and control, this isn’t very much and can allow for a lower-cost system. If you are moving video (if you are using Q-SYS’ NV products or other AVoIT Video) on the Q-LAN, then your switch will have backbone/bandwidth minimums.
• The switch must properly support QoS (Quality of Service).
• In most cases, proper support of IGMP (Internet Group Management Protocol). With IGMP there must be a suitable querier and the switches must support IGMP snooping.
• LLDP (Link Layer Discovery Protocol) should be supported.
• umbo Frames should be turned off. Keep the hop count to 5 or less with 3 or less strongly preferred.

These requirements mean that you will need a managed switch.

The Q-LAN as an AES67 network but with some extra proprietary features. AES67 and Q-LAN can and do live on the same network so if you have an SMS (Screen Management System) server (or sound processor, like the CP950A), you can feed into a Q-SYS system directly on the network instead of using the traditional AES3 audio.

The same things that allow Q-SYS networking to work also benefit AES67. *

*Dolby uses AES67 on some of their products (IMS3000, DMA amplifiers, DAC3200 series converters, and the CP950A). However, they do not work well with some typical AES67 protocols. The big one is IGMP. I’ll discuss that a bit later. Since Dolby presumes a closed system with just a handful of their devices, they can “get away” with an unmanaged switch and not worry about IGMP. If you are used to that in your other installations, just know that it is due to their closed system (not having to work with other manufacturers and there not being many devices (or non AES67 devices) that allows it; it is a special case).

Port Speed

As mentioned, the port speeds just need to be 1G (1 Gigabit/second, Gbps). That is a pretty low threshold. For an example, let’s look at the Check Design of one of my 10-plexes where 9-screens are running with 7.1 audio:

Blog25Image1.png

We’re only up to 445 Mbps. We’re not even half-way up to the network capability of that one port but 4/5ths of our way to the Core 510c’s input channel count capability. So, we will run out of input channel capacity long before we run out of network capacity, using 1G.

Another key point is, if you are incorporating video, that the Core merely switches the video. It does not have all of your video sources feeding into the Core and out of the Core (like what happens with sound and control). If the video went in and out of the Core, it would grossly exceed the 1G speed since each video feed could consume around 800Mbps, on its own. So, if you do plan to have video within your Q-SYS system, you may need to consider switches with higher bandwidth capabilities though the 1G port minimum speed remains (it’s still only moving up to 800Mbps on any one port). You may also want to create a separate LAN for your video layer to reduce the cost of your infrastructure and “right-size” each LAN to the site’s needs.

Switch Bandwidth

Switch bandwidth will only come into play if you are moving video on your network. If you have 24 ports on your switch and each are pumping nearly 1Gbps (as 4K video can do), the switch has to be able to support that throughput. As a rule of thumb, you’ll want to have 2x, minimum, internal bandwidth of your anticipated port demands. You’ll find, for audio/control, as shown above, most any switch that meets the other requirements will easily meet this. Worst case, if all 9-screens, plus the core are running at 445Mbps, we’d need a switch with a 9 Gbps backbone/bandwidth. The most common (and low-cost) 24-port switch I use has 48Gbps.

Now, if you get into also moving video and you’ll likely want larger switches (to avoid having to ensure all of your switch-to-switch connections are also very speedy; the need for 10-40Gbps trunks are not uncommon), the switch bandwidth will become a more critical specification.

[Blog-25, Page 1 of 7]

[Steve Guttag]

QoS (Quality of Service)

This is a big one (some IT people are claiming it is less so with the current crop of switches being so inherently fast but I (and Q-SYS) recommend adhering to it regardless; it doesn’t hurt anything to implement it).

QoS is a priority system where data is tagged with its priority to ensure that when a switch is presented with multiple packets of data that the highest priority data is processed first.

For Q-SYS, the highest priority is the PTPv2 (Precision Time Protocol) clock. It is imperative that all devices are beating at the exact same time or you will have “jitter.” The clock doesn’t have much data so it doesn’t take (much) time to process…the Core and peripherals are just syncing themselves to the “Grand Master” clock (aka Clock Leader). Most of the time, the GM clock is the Core itself but that is not always the case, particularly in Dolby Atmos^® systems. However, all of the amplifiers and any AES67 (or Dante…more on that later) devices still have to beat to the same clock.

The next highest priority is…? Anyone? The audio. You don’t want audio packets arriving late because some touchscreen is updating its VU meters. We’ve all experienced laggy computer systems, at some point. That would be disastrous for an audio stream. QoS ensures that, between the clock and audio, everything plays seamlessly and with minimal latency (delay). Q-SYS has a 3.17ms end-to-end latency. To achieve this, audio packets have to traverse the network in 280µs or less. This is why particular attention has to be paid to getting the clock and audio packets through without having to wait on any other networking needs.

The next one down is Video. Likewise, video, which is piggish in its own right, gets the next priority.
Finally, the rest are considered “best effort.”

AES67 devices, including Q-SYS, tag these types of data with DSCP (Differentiated Services Code Point) numbers so the switch knows their priority.

In the “Design Properties” of your Q-SYS design, you can set what DSCP values Q-SYS will use. For cinema, 90% of the time, QLAN should be the preferred one:

Blog25Image2.png

The PTPv2 clock uses DSCP Value of 46, audio uses 34 and video uses 26.

If you are working with Dolby products, they are using AES67 and even though they do not have a managed switch recommendation (remember they’re thinking about their small closed system), the clock and audio packets still must be precisely synced in our larger Q-SYS system. If you are working with their products, like the IMS3000 or DMA amplifiers, you still need to pay attention to QoS.

There are other AES67 products out there, like wall-plates for audio, microphones, and 3^rd party amplifiers like LEA and Powersoft. They too should use these DSCP values.

Dante

If you are using Dante audio equipment (a very popular A/V audio standard controlled by the company Audinate, that they license to manufacturers, including Q-SYS), then you will need to change the DSCP levels to conform with Dante’s standard DSCP values.

Blog25Image3.png

Note, the PTPv2 clock now uses DSCP value 56 and even more importantly, the audio is using 46. That is the same DSCP value of the standard AES67 clock! You don’t want to mix these up or you will have the clock competing with audio packets for priority.

This also has implications if you are setting up a Dolby Atmos^® system since you can’t change its inherent DSCP values and it is almost always the GM clock for the system.

FYI, all new Cores ship with an 8x8 software-Dante license. You can purchase a larger license up to the limit specified by your Core (not your Core’s channel count but how many Dante channels it can support). For example, the Core 24f can support up to 64x64 Dante channels and there are a LOT of Dante products out there (including amplifiers). Most Dante products can have AES67 activated, however, be sure to check if the product you are considering does have that option if you are trying to keep it all AES67.

Of note, Dante supports network redundancy, if that is important to you. AES67, at present, does not support network redundancy.

IGMP

IGMP is not strictly necessary for an audio and control system, only. If you are just using QLAN for audio, and everything on your QLAN network is a QLAN/AES67 device, you can get away with not having IGMP set up on your network switches. But it is almost always better to have it set up because:

• ]IGMP allows multicast networking without “flooding” every port/device with multicast network traffic.
  
  In a (somewhat) simple description, what IGMP does is have a querier call out to find out which devices are wanting specific multicast traffic. If the device does not say that it does, then multicast data of each Multicast IP address are not sent to that port of the switch.

There has to be one, and only one, IGMP querier and all of the switch ports (including any downstream switches) have to have IGMP snooping turned on (so that they can respond to the query). Some switches can self-arbitrate a single IGMP querier while others cannot. When setting up your switch, make sure you understand if they can or not. Also, IGMP querying/snooping does not necessarily work across switch brands. So, try to stick to a single brand across your QLAN network(s).

A benefit to IGMP with even just audio and control to IGMP are things like touchscreens. If you find that touchscreens keep disappearing on your network, IGMP will aid with fixing that. Each time the querier sends out its message, the touchscreen should respond via the switch it is connected to that it wants that traffic and keep it visible on your network.

The big “gotcha,” in our industry, is Dolby. Dolby’s products, and the IMS3000, in particular, starting with version software 3.5.x, won’t respond to an IGMP query. So, the network switch will shut multicast traffic off on that port (it doesn’t want to flood it) and that will shut off your AES67 (Atmos^®) audio. As such, if you are implementing IGMP on your network, you will need force multicast on for the Dolby products that are using AES67. A common name is to declare them “static router port” (Netgear uses “Multicast Router”) and don’t bother to enable IGMP snooping on those ports (they aren’t going to respond anyway).

LLDP

Link Layer Discovery Protocol (LLDP) is required if you plan to take advantage of dynamic pairing. Dynamic pairing has two key benefits for a cinema:

• It allows one to set up select peripherals (like amplifiers and touchscreens) such that if you have a failure, one can merely plug in its replacement and the Core will go about configuring it to function as the failed piece. This also requires that you have either DHCP set up on your QLAN networks or that you preset the IPs of your spares because the replacement has to be on the same subnet as the Core, naturally.
• It allows you to have a single lectern that you may load with a touchscreen and other A/V devices, including a Blu-ray, switcher, laptop ports, and so forth. You can then have the system self-configure to know which theatre it is in by merely plugging the lectern system in.

LLDP, essentially, lets devices know what is plugged into each specific port of a switch. So, if an amplifier disappears from port 3 of a switch in theatre 2, the Core will know that amplifier (which has its own name in the design) is to be a specific model with a specific configuration…so, if a compatible amplifier plugs into that port, the Core knows how to configure it to be a replacement for the failed unit.

Likewise, for a lectern, if the Core sees that previously configured system shows up in theatre #3, it will activate the theatre 3 lectern system. If the same system is moved to theatre #2, when it plugs into #2, the Core will activate the 2 configuration.

There isn’t a down side, that I am aware of, to enabling LLDP, only up sides and you may find that other devices benefit from it too.

Jumbo Frames (turn them off)

Q-SYS explicitly wants jumbo frames turned off. What are jumbo frames? In simple terms, they are like having a 12-lane highway versus a 2-lane one. You will find that video companies (like Visionary Solutions) will want Jumbo Frames turned on because moving video is large and having a wider highway moves that sort of data. The problem is, they get in the way of our need for a speedy audio network that lets our tiny PTP clock and then our relatively small audio packets to zip through. Remember too, video doesn’t actually enter/leave the Core so you should plan your network(s) accordingly so that Q-SYS gets what it needs while not compromising any video (or other AV over IT) needs. It can be a juggling act. (consider using separate LANs or VLANs or verifying that all data is transmitting properly). In cinema, we are mostly, for now, dealing with audio and control. So, keeping jumbo frames off shouldn’t be a struggle.

Note, most switches don’t come out and have a simple Jumbo Frames on/off tick box but most provide a place to set the value of the MTU (Maximum Transmission Units) or “Frame Size” as the number of bytes to handle at a time. Nominally 1500 MTU (typically 1518, in my experience) is the non-Jumbo Frame size and what most switches will come set to. If you want jumbo frames, it is a variable but most people seem to set it to nominally 9000 (9198-9216 are common). Note, the MTU must match on all parts of the segment (using the highway metaphor, you must have the same number of lanes from end-to-end).

[Blog-25, Page 2 of 7]

[Steve Guttag]

Keep the Hop count to 5 or less and preferably to 3 or less.

The hop count is from the Core to the device. Remember, we need to keep the latency to 3.17ms, including all processing done in the network switches. As you move above 3-hops (essentially, 3 switches), you are going make this more difficult and more prone to timing errors.

All of my cinema systems have between 1-3 hops. If it is a single screen, most use a single switch (per QLAN). For multiplexes, my topology will typically have a Central Audio Rack that will contain a pair of medium sized Cores (Core 510, Core 610) unless the screen count is small enough to use a smaller pair of Cores (110, Nano). There will be a pair of switches in the Central Audio Rack. At each screen, there will be a soundrack with another pair of switches that connect up to the DCIO, touchscreen, amplifiers and any A/V needs. In some installations, we’ll locate the amplifiers behind the screen (for the screen channels and subwoofers). Sometimes we’ll run separate CAT cables for each amplifier (if there are a small number) and other times, we’ll add another set of switches behind the screen and just run 1 or 2 pairs of CAT cables. So, that is a worst-case of 3-hops (in the drawing below, to reduce clutter, only one QLAN is shown…for a redundant network system, double the number of QLAN switches and network cables).

Blog25Image4.png

Another benefit to putting the screen amplifiers behind the screen (beside reducing the cost of pulling expensive, heavy speaker cables from the booth) is that, with Q-SYS amplifiers, there are analog inputs available for things like microphones or even other audio players for theatre rentals. The amplifiers also have GPIO terminals, which could aid in other theatre control, including drapery (masking/curtains), simple lighting without the expense of a touchpanel…etc. Plus, once you have the Q-LAN down to the screen, that could be your point of entry into the Q-SYS environment for a lectern or a wall plate like the NV-1-H-WE. And, unlike other systems, you maintain full control over those amplifiers, including monitoring their performance and even audio monitoring from their outputs! You don’t lose anything by locating the amplifiers behind the screen, except, depending on the system, serviceability (how hard will it be to get to them and how dirty will they get?).

You can certainly just increase the size of the Central Audio Switch and pull everything from there to omit the theatre and screen switches but that is going to be a much longer and harder pull for little benefit, in my opinion. You also have to keep track of your cable lengths when doing such long runs. And, if there is a cable problem, it will be that much harder to address, down the road. As the size of the switches go up, their costs grow geometrically. It will be cheaper to break it up as I have shown to 2-3 switches per theatre (per network). And, when it comes time to replace the switches, it will remain cheaper. Even some of the biggest complexes should fit nicely with the very common 24-port switches that are out there with most theatre/screen switches being 8 ports or so. It depends on how many amplifiers and peripherals you are using at each theatre.

What Switches Should You Use?

There are really three options:

1. Q-SYS sells pre-configured switches based on (at least currently, they have used Dell switches in the past) Netgear’s line of dedicated A/V switches.
2. Use purpose-built A/V switches that may have presets for Q-SYS.
3. Choose your own switches and be responsible for their correct set up/troubleshooting.

Q-SYS Switches (Option-1)

This is the “easy-street” choice. * It is as close to open-the-box and plug-it-in as you will get. Furthermore, Q-SYS is responsible for technical support for it. If you use their switches, and you run into networking issues, you can call Q-SYS (open a case) to get them to assist in resolving the issue. For this, you will pay a premium for the switch but for that, you get the commitment that it will work. You also get to take advantage of spending less time configuring your network, which is also worth something.
Because it is canned, there may be some limitations as to what you can do. You can change the IP address, for example but you should not just update it or change other parameters or load default Netgear settings.
If you want to have a mix of pre-configured but still have your hand in getting your networking topology set up your way, then option-2 may be more suited for you.
*If you have a Dolby AES67 equipment in your system, IGMP will be a problem with this option. You can put another switch between the Q-SYS supplied switch and the Dolby equipment to mitigate the problem but that would imply that you know something about switch configuration such that Options 2 or 3 might be more suitable.

Purpose Built A/V Switches That Support Q-SYS (Option-2)

With almost the same benefits as buying the switches from Q-SYS, using purpose-built switches like Netgear’s M4250 line of A/V switches hand-hold the novice networking technician. You know, people like us (well, many of us; particularly us old-timers).
Netgear even has a separate login for A/V users that really simplifies the user interface (real IT people would never lower themselves to using a Web-UI…it’s all CLI for them). Netgear has “Profiles” where you can select what will be on your network. They have one for Q-SYS Audio as well as Q-SYS with Audio and Video. There are Dante (Audinate) ones too. You apply the appropriate profile for what you are going to have on the network and ta-da…it configures itself for you! Now, you might find that your combination of features are not completely covered by an existing profile. You can modify a profile as needed to suit your particular installation. If you run into trouble, Netgear can provide support. But you need to be realistic. They are there to support their product, not turn you into a networking guru.
I don’t want it to seem like Netgear is the only dedicated A/V switch company but they are one that I and many have used. Luxul and Luminex are names I hear people using that also have an A/V line of switches.
Remember, once you move away from option 1 (using Q-SYS configured switches), the responsibility falls upon you to make sure that your selection meets your needs (ability to properly configure, enough bandwidth…etc.). Seeing which models Q-SYS is using is going to be a big clue as to which models of Netgear you should consider.

Choose Your Own Switches (Option-3)

If you are an IT professional, you can certainly use an appropriate switch that meets the above criteria and skip the added costs of having a user interface that hand-holds the typical cinema tech. Q-SYS is built on standard IT infrastructure and not a particular make/model of switch.
The cost savings by going this route can be considerable. However, more and more of the burden of proper configuration (and qualification) will fall upon you. That is, if you hook things up, configure your switch and you end up with errors/dropped packets and so forth, it will be a problem for you to solve, not Q-SYS.
Earlier in Q-SYS’ history, they used to come up with set-up sheets for known switches. Over time, this became impractical as switches have a finite production life. So, new switches would need to be qualified (from a multitude of manufacturers), with new setup sheets and then, if a manufacturer made an internal production change that adversely affected performance, who would be responsible? Q-SYS’ solution was to distribute their own pre-configured switches (option-1).
At this point in time, if you are selecting the switch on your own, they are expecting that you know what you are doing.
Here is a link to Q-SYS’ networking requirements help page:

https://help.qsys.com/#Networking/Q-SYS_Networking.htm

Unfortunately, it would seem that Q-SYS has purged most, if not all of their older documents discussing networking in favor of their on-line help (linked above). Sometimes, it is easier to figure out how to configure something, like a switch, if you can see how it has been done, even on a different make/model.
For those that need some sort of start/help, I will show how I configure one of the low-cost switches I use, in the Appendix.

How Many Networks (LANs)?

There are different philosophies on how to set up Q-SYS networking topology. My normal mode is to have both a redundant network and a redundant Core, whenever possible. However, you may find that if you are going to set up a single core per-screen (a more traditional cinema sound set up), that using a Core like the Nano or 8-Flex, you can use QLAN-A for the QLAN network and use QLAN-B like any other sound processor’s NIC and put it on the normal booth LAN. This makes installation quite easy and “traditional.” I would also untick the various QLAN services in Core Manager for LAN-B that are used for QLAN traffic. Don’t go too crazy; you’ll still want to keep things like the control services active. But you probably want to disable the various multicast services on LAN-B since you might not have the IT infrastructure to handle them properly (since nothing on LAN-B/Booth LAN should be wanting those packets).

Blog25Image5.png

The topology for a single screen (either a single or within a multiplex) might look like this:

Blog25Image6.png

In this example, the 192.168.201.x network is used for QLAN-A. The QLAN switch must meet the Q-SYS criteria. It is the installer’s preference to connect all of the QLANs together (within a multiplex) or not. Do you think you’ll need to share audio between two theatres? How about, if a Core goes down? You could have a neighboring Core run both theatres. If you choose to link all of the QLANs up, remember, there can be just one IGMP querier.

[Blog-25, Page 3 of 7]

[Steve Guttag]

I would advise having separate PTPv2 DOMAINS for each theatre. If you stick with just one Domain, one of the Cores will be the GM clock and if it needs to be rebooted/updated or whatever, when it drops off line, ALL of the other theatres will drop until a new GM is “elected” and then when the original GM clock comes back up, it will interrupt audio again as it is elected GM clock again. Using separate domains prevents all of that at the price that you can no longer share audio via any synchronized method (QLAN/AES67). It’s a tradeoff. If you do plan on just a couple of theatres needing synchronized audio for some reason (perhaps to allow for a meeting space with an overflow theatre), then just those theatres need to have the same PTPv2 Domain.

The “LAN” network is like any other normal booth “Management/LAN” network and without any managed switch requirements (but you should shut off the QLAN-B services that would, otherwise, put out Multicast traffic).

Medium Cores like the 510i, 610, X10, and X20r all have an Aux network (or two) to allow for redundant QLAN network while also providing for regular control communication via the Aux network port. The new Core 24f, what I would consider a “small” Core but it is starting to straddle the line between small and medium, also has both redundant QLAN networks AND two Aux ports for communicating on other networks, like the booth LAN. So, things are getting easier for implementing a redundant network on smaller systems.

Note, you may still wish to use the QLAN ports independently for things like Dante so that it can be on a different network (it isn’t a requirement, Dante can coexist on a QLAN network).
A key point is that if you need synchronized audio (with that low-latency), you need to use a QLAN NIC on the Core. If you canhave latency within the audio, like lobby/intermission music, then there are options to use Aux networks (e.g. use a WAN transmitter/receiver for unicast or Media Stream for multicast).

I would advise against using VLANs to convolve QLAN-A and QLAN-B networks into one switch in a redundant network system. This defeats the purpose of the redundant network (you’ll have a single point of failure). With a redundant network, you should be able to unplug your QLAN-A network switch (or QLAN-B) and the sound should continue, uninterrupted. Now, convolving Aux and a QLAN onto a common switch by using VLANs could save you a switch in the soundrack.

For my systems, I have separate LANs for all of it. There are LAN-A, LAN-B, Management (control/Aux), and Media networks. CAT cable is cheap, problems are expensive. If you use switches like the ones I’ll present in the Appendix, the network switches are also pretty low-cost.

Small Cores without an Aux NIC and Network Redundancy

Clearly, the medium and newer Cores, with their Aux ports, solves the issue of having redundant networks as well as control. So, what do we do about the small Cores like the Core Nano and Core 8-flex? (or you may have an existing Core 110f/c).

Well, we need to get creative. That is, if you only have two NICs on the Core and you want to have network redundancy, something has to give. Right? Well, sort of.

First, I would keep QLAN-A as “blessed” with just QLAN traffic on it. That will ensure that nothing interferes with audio. Single NIC QLAN devices like the smaller QIO peripherals and the touchpanels are LAN-A only devices. If you are using the SPA-Q amplifiers, they too are just QLAN-A.

If you are going to have Dante in your system, it too can travel on QLAN-A (or QLAN-B), providing you configure your design and switches appropriately. Since Dante can also be network redundant, it may also reside on both QLAN-A and QLAN-B. If you want, you can have QLAN be network redundant and have Dante be single network. It is your choice.

So, where do we connect up our control network? And how do we deal with getting control onto/off of that network and onto the normal booth network?

Put QLAN-B On Your Control Network (LAN)

If you have enough IP addresses on your normal booth network, you could add your QLAN-B on that same subnet, just like in my example above. However, if you want to go down that route, you really have to treat the entire network as the QLAN and not just the Q-SYS equipment. What I mean by that is, all of the switches have to be configured for Q-SYS traffic so that the multicast will be handled properly and QoS will be honored. If the redundant network is compromised, there is no point in having it. Its job is to ensure that if there is a problem with QLAN-A, that there won’t be a sound interruption. Additionally, without proper switch configuration, the multicast traffic could end up flooding an otherwise unmanaged network. By using proper switches and proper configuration, this can be avoided. The bandwidth of Q-SYS audio and Control are such that they should fit on a typical existing booth network. QoS will ensure those things that need priority will get them.

What you will likely find, unless you have a small complex, is that you will start to run out of IPs in a typical subnet. Right now, you need IPs for the projector, server, ADA captions, automation, maybe 3D, possibly a projector touchscreen, some have a series 1 DLP IP, a security manager on an older GDC server, possibly a network switch, video switcher…etc. They add up pretty quickly. When I settled on the IP scheme we use for digital cinema, it was based on supporting up to 40-screens, with an emphasis for 10-screens and under (I have very few complexes over 10-screens and none that are even 20-screens).
That means that I already have IPs allocated, to be consistent from theatre to theatre (regardless of size). Putting the Core and any peripherals into that mix could significantly impact your IP allotment and can easily take up 5-10 IP addresses per screen. You’ll need to look at your IP scheme and see if you can withstand the added equipment and how well it will scale in your various complexes.

The topology for a convolved QLAN-B/Booth LAN system is the same as my example above, with the exception of the switches are now managed and QLAN configured.

Blog25Image7.png

For me, it was more consistent and easier to use my normal QLAN-B IP scheme regardless if the Core had an Aux port or not. It makes network switch configuration much easier, in my opinion, because I can have templates. So, thus far, I have not used the topology shown above but there is nothing wrong if you do or find it easier for your situation.

Convolve QLAN-B and Control and Use a Router for LAN Access

This is the approach I have used, for the most part. It scales well. That is, since you can create a separate/unique QLAN-B, with its own set of cables, we get a lot of IPs to work with, even with larger complexes.

Blog25Image8.png

Your normal booth LAN is completely unaffected. You don’t need to add hardware/switches. The Central Audio switches in the diagram above are only needed if you are doing this on multiple screens. You do need to configure a gateway on LAN-B of your Core(s) the IP you assign to the Router…in this example, 192.168.211.1.

You do need to configure your router for the QLAN-B network and have routes between QLAN-B and your booth LAN. You are free to decide what ports/services are needed to pass and put whatever restrictions you or your IT department deem necessary. For most systems, people use port 1702 to send commands to Q-SYS using “ECP.” You’ll need to also allow the ports for anything Q-SYS is controlling. If you are providing remote support, you should allow the ports and services that allow for those activities too.
As mentioned, this method scales well. If you have 2, 10, or more screens, it is the same one configuration in the router and you merely need a large enough “Central Audio” switches to support your screen count.

If the Small Core is running a small plex (2-6 screens), then the topology only slightly changes such that the Small Core will connect directly into the Central Audio switches.


[Blog-25, Page 4 of 7]

[Steve Guttag]

Dolby Atmos Considerations for Network Redundancy on a Small Core

If you are not utilizing a redundant network, then an Atmos^® system can use the same topology as first presented whereby LAN-B is your control network.

Some will point out, the AES67 signal from the Dolby Atmos^® decoder (CP850, CP950A or IMS3000) is only a single network so what’s the point of a redundant network? I would counter with: “do you really want a single-point of failure like that, in your biggest house?” That is, if a $2 patch cable is making a bad connection, do you want that to bring the show down? How about if you have a failure on your LAN-A switch? If you use a DCIO (-H), you have a very reliable backup system with the normal AES3 audio that has network redundancy capabilities. Seriously, compare the investment into a Dolby Atmos^® system versus a second network switch/cables and the DCIO. And then compare the added cost to the potential of a dumped show or shows. Plus, the DCIO provides a nice off ramp for HI/VI audio to leave the system. It also has a booth monitor amp and GPIO, including 4-relays. It isn’t like it won’t be used except in an emergency. The DCIO-H also brings HDMI decoding.

Implementing a network redundant Q-SYS system with Dolby Atmos^® adds some to the considerations but, for the most part, at least in my systems, have used the same topology as was presented above whereby QLAN-B and Control are convolved on the QLAN-B network. I use a router to allow communication between QLAN-B and the normal booth LAN.

Due to the nature of these immersive sound systems, even if you are using 8-channel amplifiers (e.g. CX-Q4K8), you are still going to use on the order of 8-10 amplifiers, depending on the size of your room and the speakers chosen. If you figure each immersive sound room will consume 20 or more IPs, how many such rooms can you have on one subnet before you’ve used all of the IPs up? Realistically, if you are going to reserve IPs, that sort of scheme tops out at 11-screen complexes. As such, I’ve opted to let Atmos^® have their own IP subnet, per theatre. This is a personal preference. However, so long as you keep the PTPv2 domains of each Atmos system separate, you should be able to use a single subnet for multiple theatres, if you prefer.

Depending on your router’s capabilities (how many discrete LANs it can support) and how many such rooms you need to accommodate under one roof, you may need to modify the network topology just a bit. Let’s say you have a 10-plex and 4 of the screens have Dolby Atmos^®. That would be, in my scheme, 4 additional QLAN’s to accommodate. You could, in that situation, with just 4 systems, allow them to all use the same QLAN-B subnet. The domains must still be different (each Atmos^® decoder needs to be the GM clock of its system, still) that will keep the 4 theatres separate, as far as the network audio goes. But it allows all of the control communication to share the same IP scheme so just the single port and router in the router are used for all four theatres.

However, in order to tie the four theatres together on QLAN-B, you are still going to need a “Central” type switch. And, if you are doing that, why not set up separate VLANs for each Atmos^® theatre? Say, VLAN 101 for theatre 1, 102 for theatre 2 and so forth. Then, on your central switch for the Atmos^® QLAN-B networks, you have it take each QLAN-B in, and then output them to the router on a single “tagged” port. This is called “Inter-VLAN Routing.” You’ll need to configure your router for the 4 VLANs and have it route them appropriately to the LAN network but that beats getting a more expensive router that has enough ports to handle those 4 networks plus the other networks we’ve already discussed. This method also scales well. You could have even 10 or 20 theatres with Atmos^® and you still just need that one central switch.

Blog25Image9.png

Typical Multiplex Topology

Up until now, I’ve presented what to do with the smaller Cores with just two NICs (QLANs). With the medium Cores and even the Core 24f, since we get an Aux NIC or two, the topology gets simpler.

Blog25Image10.png

Each QLAN can now remain an “island” without a gateway and the Core(s) can talk with the controlled devices directly.

Redundant Core Considerations

Whenever you are using redundant cores, they each have unique IP addresses. An implication that you may not have considered is that all devices that are going to control the cores must send the command to BOTH cores. So, if your SMS servers have a volume command to send the fader to 7.0, you would need to send that command to both cores.

Conclusions

I’m going to start the conclusions where I started the introduction. I’m not an IT professional. I have had numerous successful Q-SYS installations (100% of them, in fact). What I have presented are my interpretations of the specifications for implementing Q-SYS networks within a cinema environment. I will, gladly, defer to people that have a better knowledge of IT infrastructure and can implement it well.
I also like to think I bring my multi-decade cinema sensibility of wanting a very reliable system that doesn’t take a cinema down (or multiple screens, if one is using one Core on multiple screens, as I often do). In fact, one of the things that drew me to Q-SYS was the network redundancy as well as Core redundancy. One has to lose two major components, at the same time, to take the system down. This is why, in my blogs, I speak towards these features of Q-SYS so much.
This blog, in particular, is not all inclusive. There are many ways one can approach networking and depending on your company’s needs, policies and IT personnel, they may differ with what I have presented…and that is okay too. My intent is to provide a starting point for those that have never attempted Q-SYS networking. For many, this might be their first venture into working/configuring managed switches. It is also, somewhat, scary to send sound over a network. Analog audio is pretty easy to figure out (and to trace). If the sound stops or starts to stutter with an IT based system, like Q-SYS, it isn’t as intuitive for the typical cinema technician. IT departments are also not going to be as well-versed on the particular needs of an AV over IT system, like Q-SYS. They may make a working network but it may end up with audio that drops/stutters and the like because they didn’t adhere to the particular needs of a Q-SYS network or are using IT equipment/switches that do not process the packets as Q-SYS needs. Q-SYS used to list switches that were known to not work properly or were otherwise incompatible with Q-SYS.
I would suggest to always start with something that works before venturing out to try something different. That way, you have something to compare against and a guarantee that you have at least one solution, even if it isn’t the most ideal. With most everything in this blog, I have either actually installed or I have tested it enough to satisfy me that it should work in the field.
I would suggest getting a small switch (and configuring it properly). Test it with just the Core and a peripheral (e.g. amplifier, maybe a touchscreen) and verify that you don’t get dropped packets and such. Once you convince yourself that you have it working, keep this switch and some cables that you can splice into a problem system to see if the problem is networking or equipment related. That is, isolate the system enough to figure out where your problem is.
I suspect that this is not my last blog on Q-SYS networking as it was never meant to be all-inclusive.
The other take-away I want to present is: I prefer separate LANs, with separate cables, over convolved networks with VLANs. CAT cable is cheap. How much more does it cost and how much more difficult is it to pull another 1, 2 or even 6 more cables? How much does it cost to go down or have problems? For me, an ideal projection booth with a Q-SYS network consists of:

• Management/Control network on its own LAN…with or without managed switches
• Media Network strictly for content transfers and Streaming shows with direct connections between the Media switch and the SMS servers in the projectors.
• QLAN-A network. (isolated)
• QLAN-B network. (isolated)
• If you have video, let it be on its own LAN too with its own (high bandwidth) switches.

This way works, every time. It is also extremely fault tolerant.

©2025 by Steve Guttag

[Blog-25, Page 5 of 7]

[Steve Guttag]

Appendix-A

Low Cost QLAN Switches

In cinema, we’re always cost conscious. The realities are, our networking needs, compared to a typical A/V set up are less intensive. For the most part, a cinema system is working with just audio and control so you can lower the requirements you need in a network switch. Remember, we’re not using even 1G on any port of any switch for Q-SYS (until you get into video, so consider my examples to be for just an Audio and Control system).

I have been using TP-Link “Jet Stream” series of network switches for many years now. The cost savings by using these are substantial. (I’m not saying that TP-Link is THE switch company at all, you may find others…many have had success with D-Link too).

If we call the street price of the TP-Link TL-SG2428P (or SG2428P…they dropped the “TL” on the current generation) to be “1” or the reference amount. To get an “equivalent” (port quantity, backbone bandwidth) A/V switch, like a Netgear, you’ll spend over 4.5 times more! It isn’t that the Netgear isn’t worth it but if you aren’t using all of its features, you might have an opportunity to save a bit. If you want that Netgear switch configured from Q-SYS, you can expect to spend more than 7-times than the TP-Link. Remember, the low-cost TP-Link isn’t coming out of the box ready for Q-SYS. So, you need to factor some time in there to configure each switch, particularly if you are not comfortable with it.

I’ve had good success with the TP-Link TL-SG2210MP (and the newer SG2210MP). It is an 8-port 1G switch with two SFP ports. It has PoE + on all 8 of the standard ports. It has no problem powering a touchscreens and other PoE devices. You aren’t going to power an NV32H, which needs PoE++. But I’d recommend powering those with an external supply rather than paying a premium for a switch that can power it.

The other TP-Link switch I’ve used is the TL-SG2428P. It has 24 1G ports and 4 SFP ports (with up to 1G on them too).
For the examples below, I’ll use a TL-SG2210MP (but the setup is the same for the TL-SG2428P)

Refresher on the switch requirements:

• You need 1G port speeds, minimum (you’d almost have to try to find something slower now).
• The switch must properly support QoS (Quality of Service).
• In most cases, proper support of IGMP (Internet Group Management Protocol). With IGMP there must be a suitable querier and the switches must support IGMP snooping.
• LLDP (Link Layer Discovery Protocol) should be supported.
• Jumbo Frames should be turned off.

Both switches are 1G on all ports…so check that one off the list.

QoS

The Web-UI has a dedicated QoS tab:

Blog25Image11.png

Set all ports to “Trust DSCP” since we want to define which DSCP values are important to us.

You can leave the 802.1p Priority set to factory defaults. DSCP Priority is where we can set what is important to a QSYS system. This series of switches allows for 7 queue levels (higher numbers are higher priority). We only have three levels that we care about before “best effort” for everything else. However, we do have two popular configuration modes: QLAN and Audinate. You could set DSCP value 46 to “7” (highest priority) for QLAN configuration or set 46 to 6 (second highest) and leave 7 for DSCP value 56, if you want to switch to Audinate. This way, if you are setting up for a typical QSYS system, you only have to switch DSCP value 56 to “0” (for QLAN) or to “7” for an Audinate (Dante) system. Otherwise, you have to reset the priorities of the other DSCP values. The choice is up to you.

I would start by setting ALL DSCP values to priority 0. Then I would set the three DSCP values we are interested in (46, 34, 26 for PTP, Audio and Video). In this example, DSCP value 46, the PTPv2 clock for a normal QSYS system is set to 7:

Blog25Image12.png

34 has been set to 6 and 24 has been set to 5.

Be sure to “Save” early and often as you make these changes. (towards the upper-right of the UI).
You next have to set the “Scheduler Settings”

Blog25Image13.png

Each port (just port 1 is shown above) has to have its scheduler type set to “Strict” for all 8 Queue priorities. You’ll need to repeat this for all of the ports. Don’t forget to Save.

QoS is now configured.

[Blog-25, Page 6 of 7]

[Steve Guttag]

IGMP

We need to set up IGMP snooping and possibly a Querier. IGMP is located in the L2 FEATURES>Multicast section. In this example, there is a Querier elsewhere on the network so it is disabled on this switch. However, we do have to turn IGMP snooping on:

Blog25Image14.png

Globally, IGMP Snooping has been Enabled for VLAN1 (the only VLAN needed for this configuration), Fast Leave and, though not strictly needed, port 8 has been set to a “Static Router Port.” What this means is that regardless of IGMP response, port 8 is going to accept Multicast packets. Port 8 is where an upstream switch that has the IGMP querier is plugged in (for this system).

If you click on the edit icon under “operation” you can configure these settings:

Blog25Image15.png

This is where you can turn IGMP querier on. I have left the Member Port Aging Time and Router Port Aging Time at their defaults. This is where a Static Router Port can be selected.

Key Tip
If you are working with a Dolby Atmos^® system or Dolby AES67 products, you will want to declare the ports where the IMS3000 or other Dolby products are as Static Router Ports. This will force them on for Multicast/AES67 traffic. Without doing that, you’ll find that the IMS3000 will not transmit its AES67 audio since its port will be turned off for not responding to the IGMP query. In fact, you can disable IGMP snooping on the ports with Dolby equipment.

Moving over to the Port Config, all ports have, in this case, had IGMP snooping enabled. Again, you would not want to enable any port with a Dolby IMS3000 server or any other Dolby equipment.

Blog25Image16.png

Don’t forget to Save and now you are done with IGMP.

LLDP

LLDP is enabled in the L2 FEATURES as well:

Blog25Image17.png ]

Tick the box for enable and click on Apply. I have kept the default parameters. Like with IGMP, move over to the Port Config and Enable Notification mode on all ports as well as TX and RX.

Blog25Image18.png

LLDP is now configured.

Jumbo Frames

This is also configured in “L2” under “Port”

Blog25Image19.png

The default is 1518 and that is the lower MTU value and makes that Jumbo frames are disabled. While you are here, if you have a QSYS Touchscreen plugged into the switch you are configuring, particularly if it is a “G2” series but really any touchscreen series, I would suggest setting the port speed for the touchscreen to 100M and to enable Flow Control. They seem to perform best with those settings. Port 6, in this example has those settings applied.

And that is about it for switch configuration with the TP-Link, with respect to Q-SYS. You still need to set its IP address. That is set over in the L3-features>Interface.

Blog25Image20.png

Add or edit to create the IP address for the switch. You’ll notice, there isn’t a way to set a gateway in the interface settings.

Blog25Image22.png

Set the IP and mask that is consistent with your IP scheme and click on apply. If you are changing its IP address, you’ll need to log back in with the new IP address. Also, don’t forget to Save (have I mentioned that before?).

If you need to add a gateway (like if you have control on your LAN-B), then you would do so from the “Static Routing” section. Since this is a layer-3 switch, it can behave, somewhat, like a router. Add that at Static Routing:

Blog25Image23.png

If you are going to create a typical gateway, your destination is 0.0.0.0. Your subnet mask would also be 0.0.0.0 and the next hop would be gateway (typically the router or the next upstream switch). In this example, the router’s IP address is 192.168.217.1 (sorry… I used a different switch for this image than the previous ones so don’t be confused by the different IP subnet).

Blog25Image24.png

Note, if you were just trying to get to the 10.10.10.0 subnet from this network, you could set the Destination as 10.10.10.0 with a mask of 255.255.255.0 and still use “next hop” as the gateway (which could be the router’s IP or even the next upstream switch. It is all a matter of how much restriction you want to place on the network.

Backing It Up

From the System tab, if you go to System Tools, you can create a backup:

Blog25Image25.png

With that backup config (which you can open in a text editor) you can change the IP address and other particulars and import the modified file for the next switch instead of manually setting everything all over again. This can make deployment go MUCH faster.

So, in conclusion, if one of downsides of putting in Q-SYS is the high cost of networking (particularly on redundant networks), just know that there are some significantly lower-cost solutions out there that work just fine. However, when you use such equipment, you are really on your own for getting things configured properly.

I hope you also noticed that configuring this switch shouldn’t take that much time. Additionally, if you check out these switches, you can see how low-cost your Q-SYS networking can be. Perhaps then, you might give a redundant network a try, even if your primary network is one of the more traditional A/V switches.

[Blog-25, page 7 of 7, End of Blog]

[Steve Guttag]

FYI, Q-SYS announced some new products at their "Activate" session this month. With respect to cinema, I think the biggest one are the MPA-Q amplifiers

MPA stands for Medium Power Amplifier. And, really, for cinema, they are small power amps. They are coming in 4 and 8 channel, just like the CX-Q.

image.png

If you can see the image above, note that they are using the "Max Power" so that would be the old "burst" power, not continuous. You can use this power rating for screen and surround channels but not subwoofers, really. Continuous is about 2/3rds of max power.

Finally, the noise specification for the amplifiers are a respectable 112dB into 8Ω A-weighted. The CX-Q amps are not very quiet (either their fans or their hiss levels...these should be). While they can bridge outputs to double the continuous/max power levels, you cannot "parallel" them to get more current to drive lower impedances.

Other notable aspects of them are that they are line-only inputs (onto the Q-LAN, not necessarily for the amplifier itself...no mic level preamps) but they do have two dry-contact relays, which could be handy for driving dimmers, masking machines...etc.

The QLAN-A port is PoE, which means that if the amplifier loses power (brownouts), the DSP/Control side can keep going so you won't be waiting for a full DSP boot up (presuming your network switches and Core are on a UPS).

The other change from previous models is a switch to put the amp into a standalone mode so that they can function like normal amplifiers where the inputs feed their respective outputs.

Though I doubt it will affect many, if any cinemas, they announced the newest of the large Cores...the Server Core X50r.

• 4096 x 4096 networked audio channels (with 10 Gbps network connection only—512 x 512 channels @ 1 Gbps)
• 1024 x 1024 network I/O streams @ 10 Gbps (256 x 256 @ 1 Gbps)
• 256x AEC channels @ 200 ms
• Includes 8 x 8 Software-based Dante channels (licensable up to 512 x 512)
• Dual redundant, hot-swappable power supplies
• 4x 10Gbps capable SFP+ ports (pre-installed 2x 10Gbps fiber / 2x 1Gbps copper RJ45; field-replaceable)
• 256 x 256 Media/WAN channel capacity
• 16 multitrack playback channels (up to 256 with optional stackable feature license)
• 4 multitrack record channels
• Onboard 960 GB media drive
• 2RU form factor

It is clearly based on a 2U Dell server with redundant power supplies. But, at 4096x4096, I suspect that it will cover every cinema, including those with Atmos!

If you are into scripting and UCI creation, they announced (and have already made available) their "Big Exam" for those that have completed the Advanced UCI/Scripting course. So, something a bit more involved where you are presented a real life type project to solve and troubleshoot and less hand-holding than the existing courses.

There were other things, mostly pertaining to meeting spaces but these are the ones that caught my eye with respect to commercial cinemas.

[Tj Hopland]

That POE to keep the 'brains' alive seems like something they should have implemented before now for something like this that was always intended to be remotely monitored but at least its here now.

I have not yet dug to deep into the specs or options but one thing I was hoping for that doesn't appear to be offered in these is the flex I/O that I think the SPAQ's have. I know others are and I have looked at doing or have done 'hybrid' systems of amps where we use these newer amps for mids, highs, and surrounds but more of an old school amp for all the bass.

A 950 you can do both analog and digital outs at the same time (within the channel count limits) but that may not be ideal logistically because you would have to do long analog line runs to the stage or lots of big copper speaker level runs both of which have their pros and cons.

With the Qsys platform you have more flexibility where you place the core and IO modules and the amps so better chance of getting the logistics vs wire runs in your favor but there always seems to be some got ya's often where the budget comes in. IF the Q amps had flex inputs that could be changed to analog outs you could then have all your screen amps near the screen and configure the ports on the Q amps which are your mids and highs to be analog outs to your old school analog bass amps.


For those that may be a bit confused a basic outline what I'm talking about here and how it would be used in a cinema, Steve may have covered it earlier so if he did just a refresher.

What I'm referring to as a Q amp past and present is a QSC amps that operate control and all the signals except speaker out on the Qsys network.

Most of the Q amps still have analog inputs like a normal amp. There was a past series where you could save money and order them without the inputs if you didn't need them but most still have them. Out of the box just like all the Qsys stuff it does nothing. Some products do have a 'stand alone' mode but that's not the norm, they assume if you are buying a Q product its talking to a core.

Many cases your amp inputs are going to be coming from some other module in the system over the network even if its all in the same rack in the booth. If its a 7.1 system you probably have a DCIO connected to the server so that's where your inputs are coming from. If its an Atmos system your 850/950/IMS3000 is sending the rendered stream over the network where it gets converted to Qlan and then sent to your amps or maybe the analog ports of the core unit if that's your jam and works out logistically. Those amp inputs are doing nothing so it was kinda cool that at one time they would let you save money and not get them.

So lets just say you have a 5.1 system with a DCIO in the booth near the projector. Lets say its a Core Nano which doesn't have any analog IO itself and it really won't matter where in the building its mounted. It just needs a little mains power and a cat cable into the QLAN network. Lets also say its a small room and you only need 2 channels of surround amp so you have single 2 channel DCA in the booth for the surrounds, makes sense, shorter speaker wire runs since the surrounds are likely closer to the booth than the screen. Screen amps are Q amps located near the screen.

With this setup screen amps get all their signals over the Qlan network. The DCA surround amp in the booth is getting its analog signal from the DCIO which has 3 line level analog outs that were often used for things like HI VIN but in this case lets say or HI VIN system is using digital signals direct from the server so those analog ports on the DCIO were not used. Using the HI ports for surrounds doesn't mean we are sending the HI mix to the surrounds. We can route anything anywhere we want in Qsys so they can be LS RS like they would be with any other config. If its 7.1 maybe the side surround are Q amps at the screen and its the rear wall that are on the DCA? Shortest speaker runs that way? Ya all seeing the flexibility you can get with this sort of platform?

Now to my original point of the so far unused input ports on the amp(s). Lets say you want a microphone to do a pre show introduction for a film and you got a 950. If you were planning ahead you could have run an analog mic cable but you didn't. You could buy a cheap wireless mic but you know how reliable those are and whats gonna happen when you have the director there speaking to a full house. What if you have a bunch of Q amps in the closet right where the podium will be?

No problem wire a mic jack to any of the amp inputs and do a little programming and you can send that mic signal through what ever sort of processing and limiting you want and send it to any speaker that is on the same Q network in the building. All your screens and lobby and bar and bathrooms on the same network? We can send that one amp input mic signal any or everywhere if you wanted to. Need 2 mics 4? No problem. Still wanna use cheap wireless? You stand a better chance of them working if the receivers are close to the mics vs say in the booth through walls and near other equipment that may be noisy.

This is just the start of the possibilities. Does the director want to talk over his movie? Any other cinema product nope, its mic or soundtrack, not both. Maybe its not a director maybe you have rented the theater for a power point presentation and they are gonna talk over a video explaining the new product. Its a 8am corporate meeting and they want the bar open but still want to hear the presentation when getting drink refills, no problem. You notice the echo is bad cuz you still get some sound coming from the auditorium, no problem dial in a little delay for the bar speakers. Everyone in the bar is a little loud and can't hear the quiet parts add a compressor for just the bar sound.

[Steve Guttag]

Nope, no flex ports on the MPA-Q. For the SPA-Q, I have plans to use them for a "VIP" room (i.e. enclosed balcony type room) so that one can have a full/separate sound system and use the flex port to feed a powered subwoofer for the small space. With the GPIO, you can give them their own volume control too (and mute).

Personally, as much as they would hate it, I would prefer the inputs to be card based. Buy the input you want and yes, it is stupid to have around 50-channels of unused analog inputs in an Atmos system. It is a waste of resources as well as money. I'd rather that money go to something that would be used.

I have two systems were the amplifiers behind the screen are also the inputs for microphones where one can mix a live performance right within Q-SYS via an iPAD.

image.png

They can also plug in a couple of stereo line sources for their own background music. As TJ notes, having on/off ramps (the amplifiers) down by the screen really opens up possibilities. Plus, since you have the network down there, if you did want to expand the system, you can put most anything, including video, that you want down there.

I'm not getting your PoE argument so perhaps I'm not interpreting it correctly. From a monitoring standpoint, my systems go to standby when not in use so you still get monitoring. If the site loses power, seeing it go off line is as valuable an information as an amp sending an error that it has lost mains power. I see it mostly for protecting the vulnerable part of the amp (like a UPS to the electronics of a DCP projector, but not for the light source itself). While it does speed up the boot up process, if you drop power long enough to drop out the amps (and likely the projector)...that show is stopping until power is stable and the people are back in the theatre anyway. The speed of the amplifier booting up isn't going to be the limiting factor.

I'm really not getting your desire to use "old-school" amps for the bass. If it were me, it would be just the opposite. The old-school amps (A/B, H) are cleaner, lower noise. I'd want them on the Mid/Highs because that is where they'll shine. Class D on the bass can hide the extra noise yet the 150V power rails give more possibilities for how power is handled. Plus, on the CX-Q amps, the power sharing allows the LF sections to use more power since the MF/HF will, inherently, use less. For Atmos, I, typically, use the JBL 5628 for subwoofers. I allow 4800-watts for them, using 2-cabinets. So, that is 1200-watts/driver, continuous. Using Max Power, that is 12,000-watts total or 3000-watts/driver. Where would the linear amplifier provide more? I've NEVER even come close to clipping the system. And, here is the cool thing, that is using just a CX-Q8K8. Half of the amplifier is used for the Center speaker (SC-424) running in 4-way, with the other half driving one subwoofer. I then add another CX-Q8K8 to drive the other subwoofer leaving half of the amplifier as a Center-Spare. The UCI provides for the re-route and all the user has to do to switch the output is move the plugin speaker connector from the primary to the backup. So, even if we lose the amplifier driving Center, at most we go down on one subwoofer. Naturally, if it is discovered that center has gone down mid-show, we have a UCI button to re-route Center to LC/RC to get back up instantly.

The only place I had planned to use linear amplifiers was for smaller spaces/screening rooms where the noise of the CX-Q is unacceptable. Either that or ditch the CX-Q for LEA or Powersoft amps. Hopefully, they'll replace the CX-Q line with something more akin to these newer models. And, hopefully, (though not likely), they'll offer "n" models without inputs as well as ones that retain the mic/line function or possibly flex. The problem with flex is that it literally doubles the cost. They have to put both input and output (DAC/ADC) in there so you are always wasting one...hence I would prefer a card system. Nothing if you don't want it, put in what you want if you need it.

If you think about it, about all that is left of pre-covid hardware are the DCIO family and the CX-Q amps. Ditching the CX-Q amps would make sense and we all know how much effort they are putting into Cinema now. Since the Core 110f v2 lost its front panel display, the OLED used for the DCIO must be based on existing stock. Sooner or later, they are going to have to make decisions on that display/unit. Either ditch cinema even more (possibly since one could, expensively, recreate much of the DCIO), or let it have a refresh. I would like the refresh, naturally. I'd like buttons on it for general purpose so one could create a basic user interface without a touchscreen, improve the GPIO, let the HDMI be a dealer installed card or, better, create a QIO-HDMI product so all industries could use it and while their at it, add S/PDIF via Toslink and Coax to it. Basically, make an SP200 but in QIO form and without the analog outputs since it would enter on the Q-LAN.