In the AV industry consultants, designers and integrators have always struggled with defining the functionality of systems.

I’m not talking about the process of gathering the requirement here but of documenting it.

We produce, mostly, great schematics which define the boundaries of the possible based on the hardware. The idea of these drawings containing black boxes which are highly configurable is not new.

Black boxes, by my definition, differ from other hardware items on a system drawing as although they may have a static number of input and output ports their core functionality is open to a high level of configuration.

A display has, potentially, a few functions. It’s a video switcher, a display, an amplifier with onboard speakers, it even has some control features including auto switching of the video switch and volume control of the amplified sound level.

Take for example a display with a single connected HDMI and RS232.

It’s reasonable to glean from a schematic alone that the functionality of this piece of hardware in this system is to display a video stream of the connected source and that power and input control will be using the RS232 port.

Contrast this with a control processor pre-Ethernet.

A control system processor does stuff.

Take a simple system with a two-button keypad and a display.

A Schematic showing a control system a content player and a display accurately describes the system. On functionality we can make some assumptions but without some additional information they are just that.

It is possible that:
Button 1 turns system on and Button 2 turns system off.

However, it is also possible that:
System turns on and off based on an internal timeclock and Button 1 raises volume and button 2 lowers volume.

To discover the actual requirement we need a functional scope which has hopefully been produced by some good needs analysis that informed the system design.

Control systems in the form of processors and touch panels with IO allowing control over 3rd party devices have been around since the 80’s and the discussion over how to specify their operation has produced little in the way of standards.

Infocomm, pre Avixa did some good work on this but this is not widely adopted across the industry. Crestron’s CAIP scheme and subsequently CSP (Crestron service providers) has, at its core, the requirement for programmers to produce a functional specification but even this is not standardised across the body of CSP’s.

DSP’s are common place in mid to large systems. Again these are of course by our definition black boxes.

But like traditional non Ethernet connected control systems DSP’s pre Dante and Digital had fixed number of inputs and outputs. Even post Digital standard such as OBAM proprietary hardware such as IO extenders also included on the schematic would ultimately define the inputs and outputs of the system.

The Functionality of the processing going on in that DSP must be defined just like a control system. The language of this definition is often tied in with the control system which provides control IO to this audio processing however audio processing has a language of it’s own. These boxes provide room and system specific equalisation, gain structure, Acoustic Echo Cancelling along with VOIP functionality.

Often the DSP tools are graphical in their nature providing a schematic like trail which defines that dynamic functionality of the DSP. In our system functionality specifications we define all interactions between control system and the audio processor.

The new world  “Not just black boxes but hidden lines”.

Although the change has been coming over the years for me the, “Dante Spoken Here”, sign at the ISE Show in 2018 all over the show were the sign that Audio over IP was now wide spread.

Now Schematics don’t just contain black boxes but hidden lines! The traditional skill of tracing a signal path through a schematic from input to output becomes a whole new skill.

A single LAN connection to a device can be obfuscating control, video and audio in that single cable and potentially multiple routes to disparate locations.

One approach to this by engineers is to view the IO potential in a traditional way and connect it all up like a patch panel. I have found systems where all 64 Dante channels are connected from DSP to Audio Desk for “future use” but for me this misses the point.

It’s the same misunderstanding as coding an object oriented code in a single file monolith.

In the world of Dante in addition to the Schematic which shows the physical connections between devices documentation showing the network routes must be created intelligently based on the functional requirements of the system.

These routes need to be well named for system maintainability and usability.

Having Multiple Dante 1, Dante 2 ,Dante 3 around a system dont mean anything. These should have a Name or Numbering convention just like cables.         

These concepts of defining the routes apply to other types of audio over digital such as USB IO.

Add to this video over IP in whatever flavour is being used or in some cases a mix of different types.

Listing video encoders and video decoders on a drawing doesn’t tell you what routing possibilities you might need to setup. Some devices in the market can be configured to be Decoders and Encoders but the Fixed IO on the device doesn’t always inform you on this without some further information.

Are devices to be matrixed or is the system designed as a one to many DA?

Are you using audio breakaway on the encoders / decoders?

And in a final twist some of these products also in addition to all of the above speak Dante so need to be included in your Dante routes.

These challenges are real for us in our day to day business where provided with schematics for a project we need to suck out the functional intent from the pre-sales design engineers and the project engineers.

We often work with the designers explaining to them the additional documentation we need to produce to clarify to the programmers and commissioning engineers what they need to implement.

• Virtual Matrix Drawings
• VLAN Network Design Drawings
• Dante Routing Naming Schedules
• GUI Functional Requirements
• Automation Functional Requirements
• Audio System Functional Requirements

If you need help with filling in the gaps reach out to us to help!

Image Credit : Julian Böck