A high-quality audio-visual (AV) system is an essential feature of today’s luxury home or office. The AV industry is benefitting. Even with the COVID-19 slowdown, the global pro AV market is expected to grow from $159 billion in 2020 to $304 billion by 2027.
When purchasing AV equipment, homeowners look for solutions that are easy to install, maintain and upgrade. Better control integration modules improve AV hardware usability. So, AV manufacturers and integrators who provide a better user experience gain more market share.
Benefits of Developing AV Control Integration Modules/Drivers
Customized drivers make life easier for everyone. Here are some potential upsides:
Faster Installation and Integration
With ready-made drivers, AV system integrators can quickly put the hardware together. So, system integrators like working with manufacturers who provide high-quality control drivers.
In case there are no drivers, integration companies can work with third-party developers to build a custom suite of drivers. Then, integrators can reuse these modules for new projects. It speeds up the integration process.
More Market Share and Lower Cost
Hardware manufacturers provide drivers to entice system integrators and consumers. So, a user-friendly integration module is a competitive advantage.
AV system integrators like to create their custom drivers because it saves money for future projects. System integrators can pass the cost savings to the home and office space owners.
Ease of Use for Customers
A professional driver developer can write integration modules for your hardware that meet the needs of the end-users. Users do not have to deal with out-of-date or complicated interfaces. Developers can help create modern interfaces that users can easily configure and control.
Crestron Drivers to Meet Homeowner Needs
We specialize in developing Crestron drivers. From our personal experience, we have seen homeowners appreciate our control modules.
Homeowners can easily set up and control their Crestron-supported home devices from the Crestron Home app. They are in control of the AV system. When system integrators help homeowners install a new system, integrators can pick and choose the drivers. So, it is easier to set up a new customer.
Our Crestron drivers help create a scalable and sustainable AV ecosystem. We work with manufacturers, system integrators, and homeowners to develop adaptable integration modules.
Please feel free to subscribe to our newsletter to learn about our Crestron drivers and other products.
Over the last 12 months the global pandemic has given us the opportunity to develop plans on new parts of our business. Modules have always been a part of our business as our work in Crestron Custom means we often have to create modules for use in our own projects.
At the same time Crestron’s long term project to move to a standardized platform for driver development has come of age with the release of the v4 SDK. Lighting Control have been involved as a close development partner on both the SDK and Crestron Home (one of the supported operating environments).
The aim of the standardized model is that drivers will be compatible across the range of Crestron systems including Crestron Home, AV Framework , DM and NVX Endpoints and in the cloud as part of Crestron XiO Cloud.
Taking an active part in the pilot program for both the drivers SDK and Crestron Home has been a satisfying project as we have been able to contribute our piece to the progress of the ecosystem both in documentation, systems , processes and flushing out features.
Our project, to setup and launch our Drivers store for Crestron Home, has been a long term investment in the systems, processes and talent we require to be a serious b2b partner across the ecosystem in the years to come.
We had working drivers back in November of 2019 but I realized that we didn’t have all of the processes and tools in place to maintain, support and be agile in our approach to new requirements at scale.
We are excited to have Neil and the team at Lighting Control working on Crestron Drivers. We hope that their enthusiasm and investment in the program will prove beneficial to all Crestron partners going forward.
Ara Seferian | Sr. Product Manager , Digital workplace Crestron Electronics Inc
Implemented an Automated Build process for our Drivers
Common Functionality coded using best practices
Base Types allowing consistency of user experience and easier testability
Code Driven User interface
Automated Documentation Build
Build Updates production Downloads directly meaning updates are immediately available
Unit Testing of helper methods and hardware interfaces.
Implemented Integration Testing using dedicated hardware.
Implemented Internal Compliance Testing of Crestron Home Driver Packages.
Server move of our existing website and upgrades to back end systems
Addition of webstore and integration of our existing support systems
Addition of new Internal and External Knowledge base systems
Creation of a Library of “how to” guides, both video and print
Creation of a bespoke licensing system with self-serve functionality
So with this base in place we are now well positioned to offer continued additional items to our Crestron Home catalogue and we are already working with manufacturers who want a partner in this field to assist them with integration with this or other platforms. With exciting new developments looming in the other Crestron platforms in the coming months we look forward to developing partnerships in this area.
Times are not normal just now and I never expected to be writing a blog post about what my business is not doing!
Practical day to day and what the business isdoing!
With restrictions on movement, and due to the nature of most of our works being Lighting Control, we are currently operating a very restricted service.
All of our on-site works for non-essential sites/projects have stopped although we continue to provide some remote support to customers.
We have a small number of projects in the development phase which the relevant team-members continue to work on from home.
The AV industry and Software industry more widely
The AV industry, as part of the larger communication sector, is classed as an essential sector and we have seen in the mainstream media examples of AV at work as part of the Covid crisis response. Supporting the daily briefings, projects to add virtual support to government committees and indeed the main parliament chambers in Westminster and Holyrood and projects helping healthcare professionals collaborate with their peers and offer their services remotely to patients.
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.
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.
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.
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.
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.
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.
this video over IP in whatever flavour is being used or in some cases a mix of
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.
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.
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.
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!
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.