Open HLX provides a set of command line programs and associated libraries for interacting with the Audio Authority HLX Series Modular Matrix System High Definition Audio/Video Switching System, which has gone end-of-life and, as a result, is no longer manufacturered or sold by Audio Authority.
However, thousands of such systems have been sold worldwide and there remains a need to interact with and control such systems.
With that in mind, Open HLX provides the following libraries:
- libopenhlx-utilities
- A set of adjunct utility interfaces and objects for working with the other Open HLX libraries.
- libopenhlx-common
- A set of interfaces and objects common to both client and server libraries and implementations.
- libopenhlx-client
- A set of interfaces and objects for building HLX clients such as command line utilities or mobile apps.
- libopenhlx-model
- A set of interfaces and objects for maintaining and manipulating HLX data and state, such as an equalizer preset or zone.
and the following command line programs, both built with the aforementioned libraries:
- hlxc
- A command line client for observing and mutating HLX state such as setting the volume of a zone.
- hlxproxyd
- A command line server that can act as a caching proxy to another HLX server, whether `hlxsimd` or actual HLX Series hardware.
- hlxsimd
- A command line server that can simulate an HLX server and, as a result, actual HLX Series hardware.
The hlxc client functions both against real HLX Series hardware as
well as the hlxproxyd caching proxy and the hlxsimd simulator.
Despite its end-of-life status, the HLX Series remains a high-value and high-function audio/video matrix unrivaled and unparalled even among actively-sold and -produced competitive products.
In most situations, an HLX system will find itself with its telnet-based Ethernet network interface disabled and tethered, via a serial cable to an AMX, Crestron, Control4, or other controller where those systems act as the primary user interface and experience surface with the HLX acting silently in the background.
However, despite its strong performance and value, whether using its serial interface or the aforementioned network interface, the implementation of the HLX Series control protocol has some notable limitations that severely limit its use as a general audio/video matrix without an intervening controller.
First, it is limited to no more than two active telnet-based network
connections. This means in a consumer/residential or
commercial/enterprise environment, no more than two hlxc or mobile
app users may be active at a time. Given the one-shot nature of hlxc
and the short background time out of mobile app platforms, this ends
up being a secondary rather than primary limitation.
Second, and perhaps more limiting, is the fact that the HLX Series control protocol does character rather than line or buffer at a time input/output and multiplexes across multiple connections at that granularity. There are two implications of this. First, particularly for query commands such as 'Query Current Configuration [QX]', the response is incredibly slow. Second, particularly when more than one connection is active, the output among any client is interleaved, resulting in unparseable and, by extension, corrupt output. This renders concurrent client usage all but unusable when more than one command request and/or response is in flight.
hlxsimd and hlxproxyd address both of these limitations by
allowing a number of client connections limited only by the system
resources on which it runs and by performing buffer at a time
input/output, speeding responsiveness of the control protocol by
1,000% or more.
If you are not using a prebuilt distribution of Open HLX, building Open HLX should be a straightforward, two- or three-step process. If you are building from the main branch, start with:
% ./bootstrap
If you are building from the main branch, a release branch, or a distribution package, continue (main branch) or start with:
% ./configure
% make
The first bootstrap step creates the configure script and
Makefile.in files from configure.ac and Makefile.am respectively
and only needs to be done once unless those input files have changed.
The second configure step generates Makefile files from
Makefile.in files and only needs to be done once unless those input
files have changed.
Although not strictly necessary, the additional step of sanity checking the build results is recommended:
% make check
In addition to depending on the C and C++ Standard Libraries and the C++ Standard Template Library (STL), Open HLX depends on:
- Boost
- CFUtilities
- CoreFoundation
- OpenCFLite (Linux only)
- OpenCFNetwork (Linux only)
- LogUtilities
- libnl (Linux only)
- libtelnet
- nlassert
- nlunit-test
- tre (Linux only)
- Doxygen (developer documentation only)
- asciidoc (man pages only)
- xmlto (man pages only)
However, nlunit-test is only required when building and running the Open HLX unit test suite.
As a familiarity to Open HLX's author and an expediency to easy integration into iOS and macOS apps, Open HLX depends on the Apple CoreFoundation framework or library. The framework may be provided on the iOS or macOS (or other Apple) platforms as a native system framework.
If you want to modify or otherwise maintain the Open HLX build system, see "Maintaining Open HLX" below for more information.
Some of the dependencies can be pulled in and are built by Open HLX itself. Most of the remaining dependencies can either be satisfied by building them directly from source, or on system such as Linux, installing them using a package management system. For example, on Debian systems:
% sudo apt-get install libboost-dev libboost-filesystem-dev libboost-system-dev libnl-3-dev libnl-route-3-dev libtre-dev libcppunit-dev asciidoc xmlto
To install Open HLX for your use simply invoke:
% make install
to install Open HLX in the location indicated by the --prefix
configure option (default "/usr/local"). If you intended an
arbitrarily relocatable Open HLX installation and passed
--prefix=/ to configure, then you might use DESTDIR to, for
example install Open HLX in your user directory:
% make DESTIDIR="${HOME}" install
If you want to maintain, enhance, extend, or otherwise modify Open HLX, it is likely you will need to change its build system, based on GNU autotools, in some circumstances.
After any change to the Open HLX build system, including any
Makefile.am files or the configure.ac file, you must run the
bootstrap or bootstrap-configure (which runs both bootstrap and
configure in one shot) script to update the build system.
Due to its leverage of GNU autotools, if you want to modify or
otherwise maintain the Open HLX build system, the following
additional packages are required and are invoked by bootstrap:
- autoconf
- automake
- libtool
On Debian-based Linux distributions such as Ubuntu, these dependencies can be satisfied with the following:
% sudo apt-get install autoconf automake libtool
On Mac OS X, these dependencies can be installed and satisfied using Brew:
% brew install autoconf automake libtool
There are numerous avenues for Open HLX support:
- Bugs and feature requests - submit to the Issue Tracker
Open HLX follows the Semantic Versioning guidelines for release cycle transparency and to maintain backwards compatibility.
Open HLX is released under the Apache License, Version 2.0 license.
See the LICENSE file for more information.