|
New Directions For SC-10 by Michael Karagosian 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. It’s 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 application?
FIGURE 1. SUPPORT FOR LEGACY SYSTEMS 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 system. 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. |
