New Directions For SC-10
by Michael Karagosian
© 1999 MKPE Consulting All rights reserved worldwide
Published in the Sept 1999 issue of System Contractor News
SC-10, formally known as the Audio Engineering Society Standards Committee (AESSC) SC-10
Subcommittee for Sound System Control, is the only control-related standards group within
the AES. The group was the outgrowth of an earlier AESSC working group titled the WG-10
Working Group for Sound System Control, formed in the early '90's. In earlier years, SC-10
was noted for its work on the AES-24 application protocol. Recently I was appointed as
chair of this subcommittee, and have taken the opportunity to review and reorganize SC-10
to take better advantage of the technologies now available in the world of networking and
software. I'd like to share my thoughts on the work this group has performed to date, and
what our reorganization could mean for future users of sound system control. It is
important to note that the opinions expressed in this article are mine, and do not
necessarily represent the thoughts of all members of the subcommittee.
Its important to understand what standards committees are about and why they exist. Standards
organizations provide a legal umbrella under which individuals who would otherwise be
viewed as competitors can work together on common technology with the intent to enhance
each other's livelihood. One of my favorite examples is the world of modems. The many
different brands of modems would never be the popular tool they are today if they all
spoke different languages. To come to agreement on that language, the modem makers meet
under the direction of a standards committee, where they work together to develop and
agree on new shared methods that will ultimately enhance their business.
Under the protective cover of a standards organization, competitors can work together
without fear of legal reprisal by others in the same industry. To maintain this legal
protection, the standards organization abides by strict rules that govern how discussions
take place and the openness in which these discussions are made. A standards committee is
NOT a think tank or a research and development organization, a common misconception that
has often been applied to SC-10. While the writing of a standard may be sponsored by a
standards organization, the actual development effort behind the standard is always
provided by private industry.
This background information is useful in understanding how AES-24 began, and why we are
moving in a different direction today. The original direction from WG-10 and continued in
SC-10 was to work towards a standard for a common sound system control protocol. This
protocol would ideally support the concept of inheritance as applied to the control
objects, a feature which I will describe in more detail later. While the concept for the
protocol was solid, the idea wasn't popular among those companies whose livelihood was
based on sound system control.
There were good reasons for this rejection. Amplifier producers were the primary users
of non-MIDI sound system control at the time, and their involvement was essential in
developing an industry standard. But the amplifier industry in general does not support a
business model based on standard control systems. Unlike the lighting and effects
industry, where product features have wide variance and a common control method is
desirable, the audio amplifier market doesn't tolerate performance variation and relies
upon proprietary control methods to differentiate product. Stated differently, the
amplifier is essentially a "vanilla" device, i.e. to be marketable, all
amplifiers must sound good and have volume controls, etc. The prevalent feature that
distinguishes one brand from another is the control system. Because of this, amplifier
producers actually want to have different control methods from their competition as
another means to foster brand loyalty. While this logic may seem counter to the open
standards ideology that has driven the desktop computer and the internet, it has worked
for the amplifier industry.
Without strong support from the manufacturers, the momentum for a common control
protocol came from the consulting and systems integrator community, who stood best to
benefit by a standard. There were a few significant periods where some companies jumped
in, and eventually out. What was missing, however, was a marketing model for how a common
control protocol would benefit all producers of control systems. Without a clear ability
to profit from a standard, it was difficult to keep the attention of the very companies
for whom it was intended. In the end, AES-24 languished.
None of this is to say that the ideas behind AES-24 were poor, or that the work that
was performed was insignificant. In fact, the work behind AES-24 has contributed to
several control systems now available in the industry, and one can expect that there will
be more to come. AES-24 is rich in features, among them the ability for objects to inherit
the properties of parent objects. This methodology allows a standard "parent"
fader controller to be created, with the built in capability for an enhanced
"child" fader to be introduced without rendering the standard fader obsolete.
This leaves lots of room for innovation and customization without losing basic
functionality. Control systems not equipped with a custom controller for the enhanced
object will still effectively control the object using the standard controller. This is a
timeless concept for control systems, which is why I believe that much of the work
performed for AES-24 will find relevance as this segment of the audio industry matures.
As AES-24 gets relegated to the shelf, there are other efforts backed by more involved
industries that we should pay attention to. In recent years, a parallel effort has
significantly evolved in the Entertainment Services and Technology Association, otherwise
known as ESTA. Their work on a common control method for entertainment systems is now
headed in a similar direction technically to that of AES-24. In stark contrast to SC-10's
AES-24 effort, ESTA's Technical Standards Program is financially supported by no less than
50 companies in the entertainment industry. Its Advanced Control Network (ACN) protocol
task group has the direct involvement of 9 companies who provide engineering-level support
for the development effort. Most notably, the ACN task group has asked for liaison support
from the AES in their effort to include sound system control in their protocol. It has
become one of my goals in SC-10 to support this request.
Another protocol of interest is the Simple Network Management Protocol, known as SNMP.
Developed as a standard expressly for the networking world, SNMP is finding limited
application in sound systems. The idea of using an existing standard is very appealing,
but the economics of SNMP are not so attractive today. Off-the-shelf SNMP management
software can cost anywhere from $4K to $40K, depending on the size and features of the
system, making alternative methods much more attractive.
Not only are other protocols available or in development today, we should closely study
the recent advances in software and networking technology. To better appreciate how to
apply these advancements, let's step back and look at the big picture for sound system
control. The motivation for a single control protocol stemmed largely from the desire to
control a sound system from a single application. To go a step further, it is desirable in
many installations to control an entire venue, lighting, HVAC, etc. from a single
application. Various audio manufacturers have tried to satisfy this need with proprietary
software. But this is where the business model for proprietary control methods breaks
down. The cost of developing and enhancing proprietary control systems for a broad and
growing applications market can be astronomical.
What the industry needs is a model for growth that embraces both legacy systems and
open systems. The solution that is now gaining recognition by the audio manufacturers is
to develop control methods that travel on Internet Protocol, commonly referred to as IP.
If we were to look inside the internet connection that has become part of our daily lives,
we will find that our browsers and email utilize many IP-based protocols daily, including
HTTP, HTTPS, FTP, SMTP, and POP. In a similar manner, one can place many IP-based control
and monitoring protocols on the same office-style Local Area Network (LAN). Herein lies a
model for our industry. By moving towards a custom IP-based protocol and the corresponding
interface devices required to support their legacy system, companies can support older
product over newer IP-based networks, as shown in Figure 1. The question then arises as to
how to control the various IP-based control and monitoring protocols from a single
FIGURE 1. SUPPORT FOR LEGACY SYSTEMS
FROM IP NETWORKS
Fortunately, this is where recent advancements in the software and networking industry
come into play. As we seek ways to minimize the effort for creating custom control
applications, the software industry has developed its own solution for lowering the cost
of custom software. The result is what is termed component technology. Commercially, it
comes to us in the form of Microsoft's Active-X Controls, or Sun Microsystems' JavaBeans.
Behind these technologies are other common methods for communicating between programs. In
the Microsoft world, this is embodied in COM or DCOM, for Component Object Model (or
Distributed COM), and in the Unix world, it's called CORBA. For some, CORBA stands for the
Concerned Off-Road Bicyclists Association, but in the Unix world, it stands for Common
Object Request Broker Architecture. Just in case you were wondering.
ActiveX Controls can be used in Microsoft products such as Front Page (creating
browser-viewable control screens), Visual C++, Visual J++, and Visual Basic. JavaBeans can
be used in products such as Symantec's Visual Café and Microsoft's Visual J++. While
these applications require programming capability on the part of the user, the amount of
skill required to program these applications is within reach of those who routinely
configure today's computer control systems.
With component technology, it becomes possible to create single applications that
communicate with a variety of products, regardless of the protocol used. This may appear
to be a simplistic view, and in some ways it is. For a company to develop a sophisticated
network for their products, functional layers such as a device manager and device
registration method are required. Those companies that have invested significantly in the
development of these layers are not going to simply give them away. However, as long as
these functional blocks are componentized, they become portable and can be seamlessly
included in a single application. Figure 2 presents the relationship of the various layer
of the application, including the GUI, the device components, the device manager, the
registry, and the network interface.
FIGURE 2. SIMPLIFIED COMPONENT MODEL
Component technology does not only apply to audio devices. It's just as conceivable to
implement components for the various layers in ESTA's ACN control network, HVAC control
systems, as well as proprietary sound system control networks. It should be possible for a
trained technician to create applications based on components where the various networked
control methods exist side-by-side.
As a means to provide single application control for products from a wide range of
manufacturers, component technology offers great value to our industry. To help encourage
the use of this technology in the audio industry, we have formed a new components working
group in SC-10 titled SC-10-05. Our focus will be on guidelines or standards concerning
the device level component. Standards related to the device component can be very useful
to those who build the applications. Ideally, we will describe the full Application
Programming Interface (API) of the device component to the other layers of the control
Changing direction is not enough to help SC-10 attain its full potential as a tool for
the audio industry. To keep SC-10 on track, I have formed a task group whose sole purpose
is to monitor industry feedback and relay that information to the chairman. For the
chairman of this task group, I have selected Fred Ampel, president of Technology Visions,
and an editorial consultant for SCN. Fred has been very active in SC-10 for many years, I
can count on him to keep the fire burning in the pit.
Is AES-24 dead? Not really. Previous work on AES-24 will readily contribute to much of
the new work now on the plate for SC-10. The subcommittee's reorganization has received a
lot of support from the industry, and I'm looking forward to working with industry players
to create useful standards that enhance their business. Ultimately, our effort should give
system builders more flexibility and better tools from which to create innovative designs.