WO2010080600A1

WO2010080600A1 - Virtual audio simulation and signal injection

Info

Publication number: WO2010080600A1
Application number: PCT/US2009/068703
Authority: WO
Inventors: Derek Wearin Lieb; Gerrit Eimbertus Rosenboom; Paul Franklin Vernon
Original assignee: Qsc Audio Products, Llc
Priority date: 2008-12-18
Filing date: 2009-12-18
Publication date: 2010-07-15

Abstract

An audio simulation system allows a designer to specify a test signal to be injected at particular points throughout a simulated large-scale audio system. A system designer defines the components of a design through a user interface that displays audio components as on-screen virtual objects that the designer can connect, configure, and test. The system receives a selection of a signal injector component and an identification of a pin or wire to which the designer wants to inject the signal from the signal injector component. The system simulates the behavior of the large-scale audio system to produce results similar to the output of the system if the designer physically connected the specified signal to the represented physical point within the system. Thus, the designer can test the system with various inputs while sitting at a desk rather than having to go to the location of each component.

Description

VIRTUAL AUDIO SIMULATION AND SIGNAL INJECTION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Patent Application No. 12/338,953, filed on December 18, 2008 and titled VIRTUAL AUDIO SIMULATION AND SIGNAL INJECTION, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Large-scale audio systems are used to distribute and control audio throughout a large area, such as an airport or amusement park. One example of a large-scale audio system is a public address (PA) system. PA systems at their simplest include a mixer, amplifier, and loudspeakers that are used to reinforce a given sound (e.g., a person making a speech, prerecorded music, or a message) and distribute the sound to occupants in a building or other area. Small PA systems are often used in venues such as school auditoriums, churches, and small bars. Larger PA systems are widely used in institutional and commercial buildings to provide information, coordinate events, or inform occupants of danger. Intercom systems, which are often used in schools, also have microphones in each room so that the occupants can reply to a central office.

[0003] Large-scale audio systems may be highly distributed. PA over IP refers to PA paging and intercom systems that use a network instead of a centralized analog amplifier to distribute audio to multiple desired locations. Distributed network attached amplifiers and intercoms provide communication functions. A computer running custom software often controls the routing of audio. Such systems may include multiple zones (e.g., terminals in an airport) to which an administrator can distribute audio or other information. For example, using a microphone connected to a sound card of the computer the administrator can page selected zones. The system broadcasts audio data over the network to the network attached amplifier and intercom modules. The networked attached amplifier and other audio components are small, dedicated network appliances with a network address just like any other computer on the network. Because the system is connected using a standard network and/or the Internet, a system installer can tie multiple remote sites together so that one location can be used as a source of audio to any or all other locations whether they be around the corner or around the world. A control center can also be located at multiple locations.

[0004] Although such systems provide enormous flexibility, they are also difficult for administrators to control and configure, based on the high number of options and possible combinations of audio sources, audio processing devices, and output locations. In the example of a typical airport, there are numerous audio sources including microphones at each gate for making announcements related to the gate, central microphones for making broadcast announcements, background music sources, sports or other feeds that may be played in restaurants, news feeds, and so forth. In addition, the areas in which large-scale audio systems are installed are often frequently changing. For example, airports frequently add new terminals or gates, amusement parks often add new rides, and so forth. Each of these areas may include many different sub-zones for receiving audio output, such as retail stores, gates, rides, bathrooms, employee lounges, and so forth and a different type of audio may be suitable for each area.

[0005] Another difficulty is testing the proper operation of such systems. In many installations, the components are so numerous and distributed that it would be difficult to go to each audio component location and verify that it is properly set up. However, an administrator wants confidence that the system is operating correctly.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a block diagram that illustrates components of the audio simulation system, in one embodiment.

[0007] Figure 2 is a flow diagram that illustrates the processing of the connect injector component of the audio simulation system, in one embodiment.

[0008] Figure 3 is a flow diagram that illustrates the processing of the process injector component of the audio simulation system, in one embodiment.

[0009] Figure 4 is a flow diagram that illustrates the processing of the disconnect injector component of the audio simulation system, in one embodiment. DETAILED DESCRIPTION

Overview

[0010] An audio simulation system is described herein that allows a designer to specify a test signal to be injected at particular points throughout a large-scale audio system. A system designer or other administrator starts by defining the components and configuration of the system using a design user interface (Ul) that displays audio components of the system as on-screen icons or other virtual objects that the designer can connect, configure, and test. The design Ul receives information about available audio components in the system. For example, the design Ul may receive information about audio sources (e.g., microphones, radios, and pre-recorded messages), audio processing devices (e.g., mixers, amplifiers, and equalizers), and audio output devices (e.g., speakers, recording devices, and graphical displays). The design Ul presents a library of available audio components that the designer can drag or perform other visual manipulations to place within the design. The designer configures components by connecting components together and modifying configuration settings (e.g., a gain of an amplifier).

[0011] The user interface includes connections, called wires or nets, between components that the system displays to the user. Components have pins that specify the inputs and outputs of the components and to which the wires are connected. The system receives a selection of a signal injector component. For example, the user may select to inject a sine wave, pink noise, MP3 file, or other input. The system also receives an identification of a pin or wire to which the designer wants to inject the signal from the signal injector component. For example, the designer may click on a particular pin in the user interface. The system simulates the behavior of the large-scale audio system to produce results similar to the output of the system if the designer physically connected the specified signal to the represented physical point within the system. Thus, the designer can test the system with various inputs while sitting at a desk rather than having to go to the location of each component. This allows the designer to spend more time verifying important scenarios and producing a working configuration of the large-scale audio system. Audio Simulation System

[0012] Figure 1 is a block diagram that illustrates components of the audio simulation system, in one embodiment. The audio simulation system 100 includes an item inventory component 110, a user interface component 120, a design store component 130, an audio processing engine 140, a connect injector component 150, a process injector component 160, a disconnect injector component 170, and a device communication component 180. Each of these components is described in further detail herein. The system 100 is connected via a network 190 to one or more audio devices 195. For example, the network may be the Internet, a wired local area network (LAN), or a wireless network. The audio devices 195 can include many different types of devices, such as microphones, speakers, equalizers, amplifiers, and so forth. The audio devices 195 connect to the system via the network 190. The audio devices 195 may include an internal networking interface (e.g., a built-in network interface card (NIC)) or may be connected to a component for converting information received from the network (e.g., TCP/IP packets) to audio information (e.g., digital or analog audio data) understood by the audio devices 195.

[0013] The item inventory component 110 tracks information about audio devices that are connected to the audio simulation system 100. For example, when a system installer adds a new speaker, amplifier, equalizer, or other audio device to the system, the item inventory component 110 receives information about the device. For example, the system installer may manually enter information about the new device, such as an Internet Protocol (IP) address for communicating with the device, capabilities of the device, configurable values of the device, and so forth. Alternatively or additionally, the item inventory component 110 may automatically discover new devices that are accessible to the system 100. For example, the new device may broadcast information about itself on a network to which both the system 100 and audio device are connected. The system 100 may also periodically broadcast an invitation for new devices to report their information to the system 100.

[0014] The user interface component 120 provides a user interface through which a designer can create an audio system design that includes one or more audio devices. The user interface component 120 may display a list of available audio devices or allow the designer to search audio devices managed by the item inventory component 110. For example, an item inventory for an airport might include each speaker, television, and microphone connected to the system 100. The designer places a representation of each audio device in a displayed layout. The designer may also connect audio devices together, using displayed connections (e.g., wires). For example, the designer may connect the output of a microphone to the input of an equalizer, and the output of the equalizer to the input of a speaker.

[0015] Each audio device may include one or more inputs and outputs that the designer can connect in groups or separately. For example, a designer may connect an 8-port equalizer to an 8-port amplifier in a single group. As an alternative example, the designer may connect four ports of the equalizer to one amplifier and the other four ports of the equalizer to a separate amplifier. The connections that the designer defines represent the routing that the system will perform live when the system is in use. For example, if an equalizer is connected to an amplifier, then the system will route packets sent over the network by the equalizer to a network address of the amplifier. [0016] When the designer is finished laying out and connecting audio devices, then the designer saves the design to the design store 130. The design store includes information about each audio component in the design as well as each connection between the audio components. The design store 130 stores the design as one or more data files. The design store 130 may store the files in a database, file folder, or other suitable storage facility for later retrieval.

[0017] The audio processing engine 140 simulates the behavior of the audio system to allow the designer to make verify and make changes to the design from the user interface. The audio processing engine 140 maintains an execution list that includes each of the components in the design. During simulation, the audio processing engine 140 invokes each component to process audio in the manner appropriate for that component. For example, a mixer component combines audio signals from multiple inputs into one or more output signals. The audio processing engine 140 is described in further detail herein.

[0018] The connect injector component 150 inserts one or more signal injectors into a design for testing. For example, a designer may select a signal injector component and attach it to a wire or pin in the design. The signal injector component may produce a sine wave, pink noise, prerecorded message, or other test audio signal. The designer can attach the signal injector component to the system and the connect injector component 150 modifies the execution list and other elements of the audio processing engine 140 to ensure correct simulation of the audio system with the injected signal. [0019] The process injector component 160 produces the signal specified by the signal injector and overwrites the original signal with the injected signal at the point in the system where the designer attached the signal injector component. For example, if the designer attaches a sine wave signal injector after a prerecorded audio component, the sine wave replaces the output of the prerecorded audio component during simulation. Then, the designer can watch the effects of the injected system as it passes through the system to equalizers, mixers, meters, and other audio components.

[0020] The disconnect injector component 170 performs the opposite function to the connect injector component 150 and removes a signal injector component from the design. This may include removing the signal injector from the execution list, replacing the association between an original component and another component to which it is connected in the design, and so forth.

[0021] The device communication component 180 communicates with audio devices connected through a network 190 to the system 100. The device communication component 180 communicates with new devices that a system installer connects to the system to determine the type of device, network address for reaching the device, capabilities of the device, any friendly text name given to the device, and so on. The device communication component 180 may work with the item inventory component 110 to build the inventory list of connected audio devices. The device communication component 180 also forwards control instructions based on user actions to audio devices. For example, if a user dials a knob up in a control panel, then the device communication component 180 determines the device or devices affected by the knob and sends control instructions to the devices that causes the devices to increase volume or perform other functions (e.g., adjust a roll- off frequency) indicated by the knob.

[0022] The computing device on which the system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may be encoded with computer-executable instructions that implement the system, which means a computer-readable medium that contains the instructions. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.

[0023] Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.

[0024] The system may be described in the general context of computer- executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

Audio Processing Engine [0025] Using the audio simulation system, a designer constructs a design that includes components (audio processing elements), wires (nets), and pins (points on the components to which the nets connect). For example, a mixer component may have eight input pins and eight output pins. A designer may connect a gain to an input pin of the mixer component and an output device (e.g., a speaker or file) to an output pin of the mixer component. The audio simulation system assigns an identifier to each component, wire, and pin of the design. For example, the system may assign a sequentially increasing number or a globally unique identifier (GUID). The system stores data about each wire that is connected to each pin. The information about the components, wires, and pins and how they are connected describes a design. The system allows the designer to save the design for later manipulation and to export software code for implementing the design. The exporting process compiles the design to create data structures that can be executed by the audio processing engine described herein.

[0026] In some embodiments, the audio simulation system exports the design as one or more classes (e.g., C++, .NET, and so on) that represent each component in the design. The classes derive from a common base class that defines the interface through which the audio processing engine interacts with the components. Each class includes zero or more pointers to input buffers that hold data for the input pins of the particular component the class represents and zero or more pointers to output buffers for each of the output pins. For example, a sine generator component has zero inputs and one output, an equalizer component has one input and one output, a meter component has one input and zero outputs, a mixer component has two or more inputs (one would be possible but of limited use) and one or more outputs, a crossover component has one input and two or more outputs (but could be made of high and low pass filters), and so forth. The system allocates a buffer to store data for each wire. Typically, the input and output buffer pointers of each component point to various wire buffers. Data passes from one component to a wire buffer and from the wire buffer to another component based on connections specified by the designer in the design.

[0027] In some embodiments, output pins may "fan out" to multiple input pins (i.e., an output pin connected to more than one input pin). The system treats the multiple connections as one wire, since each wire will store the same data from the output pin.

[0028] The base class defines a virtual "process_audio" function that each derived class overrides to perform actions appropriate for that component. The process_audio function for each class receives data from the input buffers, modifies the data, and writes data to the output buffers based on the modifications. For example, a mixer component combines input data from two or more different input buffers and places the data in one or more output buffers. [0029] The audio simulation system maintains a list or other data structure (e.g., a vector) with pointers to each of the components that make up a design. For example, the system may maintain a vector ordered by a topological sort (a standard algorithm in graph theory) of the design. The topological sort ensures that the system processes components in an appropriate order to correctly manage dependencies among components. The audio processing engine traverses the vector of pointers and calls the "process_audio" function on each component instance. For example, the following pseudo code illustrates the steps performed by the audio processing engine: run( vector_number ) { for i = 0; i < n_components; i++ execution_vector [i] ->process_audio( vector_number )

[0030] The audio processing engine processes audio in chunks of data called vectors. A vector can be as small as one sample or much larger. The system determines the vector size based on latency and efficiency. Too small of a vector size is inefficient, but too large and the gap between processing of samples becomes large enough to create noticeable latency. As shown in the pseudo code above, during a particular cycle the audio processing engine iterates through each component passing a number identifying the current vector to process audio as appropriate for the component.

[0031] The audio processing engine carries out the described process for as long as the system is running, processing each vector of data in turn. A designer may use the user interface to build the design, run the design for a while to test its operation, stop the design, and make further modifications. The system allows the designer to perform this cycle repeatedly in an easy to use and safe environment until the designer is happy with the results of the design and is ready to deploy the design to physical components.

Signal Injection [0032] Using the audio simulation system, a designer can inject a test signal into a particular point in the design to verify the results of the design as the signal passes through various components. The audio simulation system allows the designer to select a signal injector component and attach it to any wire or pin in the design. The signal injector component has two parts. The system places the first part (injector first) in the design at a location specified by the designer to indicate what kind of signal is to be injected (e.g., test tone, pink noise, recording, input microphone, multiples of these passed through a router, and so on). For example, the system may offer a list of multiple signal injector component types or a single type with a property that the designer can set to specify the type of signal that the component will generate. The first part of the signal injector component has one input and zero outputs (like a meter component).

[0033] The "process_audio" function of the first part of the signal injector component copies the data to be injected into a double-banked temporary buffer (the component uses the first bank for even vectors and the second bank for odd vectors). The component shares the double-banked buffer with the second part of the injector. The following pseudo code illustrates the processing of the first part of the injector: i nj ector_fi rst : : process_audi o( vector_number ) { doubl e_banked_buffer [vector_number&l] = *p_buffer

}

[0034] As the audio processing engine processes audio, the system replaces the original input signal at a particular location with the injected signal. This implies that the injected signal needs to be copied into a buffer location after the buffer has been written by the component that normally produces the signal at that location and before any component has had a chance to read the signal at that location. The design compile process produces a dictionary (e.g., map) that maps wire identifiers to: 1 ) a pointer to the audio buffer (p_buffer) for each wire and 2) an index in the execution vector (index) of a component that writes to the audio buffer. [0035] In some embodiments, the system produces the original signal even though the injected signal will replace the original signal. There are several reasons for the system to do this. First, the audio processing of any particular component might be generating multiple outputs, and the injected signal may only be replacing one of the outputs. Thus, the system still uses the original signal for the remaining outputs. Second, the audio processing may create state information that is continuously updated by the audio processing, such as internal variables of a filter component, the delay buffer of a delay component or the averaged measurement of the input signal computed by a dynamics component. When a user removes the injected signal, the state will be correct because the system processed the audio even though the injected signal replaced the original audio.

[0036] The second part of the signal injector component (injector_second) is not represented in the user interface, but is a component in the audio processing engine. The second part contains a pointer to the original component (p_component) and a pointer to the buffer to which the original component writes (p_buffer). When the injector is connected to a wire, the system consults the dictionary to find the buffer pointer and the component index for that wire. The system looks up the component pointer in the execution_vector using the index. Next, the injector (second part) is initialized with the buffer pointer and component pointer. Finally, the system changes the pointer in the execution list to point to the injector component. The following pseudo code illustrates the process of hooking up the signal injector: connect_i nj ector ( wi re_i denti fi er ) { p_buffer = di cti onary [wi re_i denti fi er] . p_buffer ; i ndex = di cti onary [wi re_i denti fi er] . i ndex ; i nj ector . p_buffer = p_buffer ; i nj ector . p_component = executi on_vector [i ndex] ; executi on_vector [i ndex] = &i nj ector ; }

[0037] Figure 2 is a flow diagram that illustrates the processing of the connect injector component of the audio simulation system, in one embodiment. The component is invoked when a designer inserts a signal injector into a design. In block 210, the component receives an attachment point in the design to which the designer wants to attach the signal injector. For example, the designer can select any wire or pin in the design to which to attach the signal injector. In decision block 220, if the attachment point specifies a pin, then the component continues at block 230, else the component continues at block 240. For example, the designer may have selected a wire or a pin. In block 230, the component identifies the wire attached to the specified pin. In block 240, the component accesses a dictionary to determine the buffer and audio component index associated with the identified wire. For example, the system may create the dictionary when the designer saves or compiles the design.

[0038] In block 250, the component associates a pointer to the buffer with the signal injector. In block 260, the component looks up the audio component associated with the index. For example, the system may maintain an execution vector of components to execute, and the index specifies a location within the vector. In block 270, the component associates a pointer to the audio component with the signal injector. For example, the signal injector may include a pointer to the original audio component. In block 280, the component modifies the execution list at the index location to point to the signal injector. In this way, the audio processing engine will invoke the signal injector in place of the original audio component at the indexed location. After block 280, these steps conclude.

[0039] The process_audio function of the injector (second part) calls process_audio on the component it points to first. This allows the original input component to perform its normal function. Then, the injector copies a vector from the double-banked buffer (shared with the first part) into the same buffer to which the original input component writes. This effectively overwrites whatever the original component placed in the buffer so that the next component in the chain will pick up the injected data instead of the original data. On even vectors, the injector (second part) copies from the second bank and on odd vectors the injector copies from the first bank (opposite the first part). The following pseudo code illustrates the process audio function: i nj ector_second : : process_audi o( vector_number ) { p_component->process_audi o( vector_number ) ; *p_buffer = doubl e_banked_buffe r [~vector_number&l] ;

[0040] Figure 3 is a flow diagram that illustrates the processing of the process injector component of the audio simulation system, in one embodiment. The component is invoked for each vector sample when a designer has placed a signal injector into a design. In block 310, the component stores the input of the signal injector in a signal injector buffer. For example, the signal injector buffer may include a double-banked buffer and the component may store the input in the even bank. In block 320, the component invokes the original audio component to place audio data in the output buffer. For example, if the original audio component is a prerecorded file, then block 320 causes the original audio component to place the next vector of prerecorded file data in the output buffer. In block 330, the process injector component copies the signal injector input from the signal injector buffer into the output buffer. For example, if the signal injector is a sine wave, then block 330 copies the current vector data for the wave to the buffer. The data overwrites the data of the original component. When the next component attached to the output is processed (e.g., in the next loop iteration of the audio processing engine), then the next component receives the injected audio data. After block 330, these steps conclude.

[0041] In some embodiments, the audio simulation system allows the designer to connect the signal injector component to pins in addition to wires. When the designer connects the injector to a pin, the system retrieves the identifier of the wire to which the pin is connected from the pin and the process continues as though the injector were connected to the wire.

[0042] In some embodiments, the audio simulation system uses a linked list for the execution list. If a linked list is used instead of a vector, the injector component can be inserted in the list after the producer and before the consumer. However, a vector is more efficient to traverse, occupies less memory, and has better locality of reference than a list, which results in better cache behavior.

[0043] In some embodiments, the audio simulation system provides a signal probe component to measure signals at a particular point that is the complement of the signal injector component. However, the probe can be simplified because the system can place the second part (probe_second) at the end of the execution vector (unless audio buffers are re-used, which may be helpful for memory-constrained machines). [0044] In some embodiments, the audio simulation system allows the designer to connect and disconnect one or more signal injector components live during simulation. For example, while the system is playing or otherwise processing audio, the designer may attach an injector to a particular point, watch the results, detach the injector, reattach the injector somewhere else, and so forth. This allows the designer to dynamically see the effects of inserting the injector. For example, if the designer is not receiving the expected signal from a particular component, the designer may connect the injector at a point upstream to determine whether the results change.

[0045] Figure 4 is a flow diagram that illustrates the processing of the disconnect injector component of the audio simulation system, in one embodiment. To unhook the signal injector, the system performs the following pseudo-code: di sconnect_i nj ector Q { executi on_vector [i ndex] = i nj ector->p_component ; }

[0046] This code is further illustrated in Figure 4. In block 410, the component identifies the index of the signal injector in the execution list. For example, the component may store the index at connection time in the injector data structure. In block 420, the component identifies the original audio component responsible for data in the output buffer. For example, if the injector was inserted between a mixer and an equalizer, then the component identifies the mixer. In block 430, the component places the original audio component in the execution list at the identified index location. In the previous example, this reconnects the output of the mixer with the input of the equalizer. After block 430, these steps conclude.

[0047] From the foregoing, it will be appreciated that specific embodiments of the system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, although audio devices and control have been described, the techniques described herein can be applied to video and other types of data as well. For example, the system may provide for the injection of video signals (e.g., a test scene with color bars). Accordingly, the invention is not limited except as by the appended claims.

Claims

CLAIMSI/We claim:

1. A computer-implemented method for injecting a test signal into a simulated audio system, the method comprising: identifying a connection between components of the audio system between which to insert the test signal; identifying a source component that provides data to the connection; replacing in an execution data structure the identified source component with a signal injecting component; invoking the signal injecting component to generate the test signal; and providing the generated test signal to a destination component that receives data from the connection.

2. The method of claim 1 wherein the signal injecting component first invokes the source component to generate output and then overwrites the output with the test signal.

3. The method of claim 1 wherein replacing the identified source component comprises replacing the identified source component while the simulation is running.

4. The method of claim 1 wherein the connection specifies a representation of a wire between the source component and the destination component of the audio system.

5. The method of claim 1 wherein the test signal is a sine wave and providing the generated test signal comprises copying sine wave data to the destination component.

6. The method of claim 1 further comprising disconnecting the signal injecting component by replacing in the execution data structure the signal injecting component with the identified source component.

7. The method of claim 1 wherein the signal injecting component includes a double banked buffer and wherein the signal injecting component copies the test signal to one bank on one cycle and the other bank on the next cycle.

8. The method of claim 1 wherein the signal injecting component includes two parts, one that generates the test signal and is displayed in a user interface and another that provides the test signal to the destination component and is not displayed in the user interface.

9. The method of claim 1 further comprising, displaying in a user interface the source component, destination component, signal injecting component, and identified connection.

10. The method of claim 1 wherein the identified connection is a pin, and the method further comprises identifying a wire associated with the pin.

11. A computer system for simulating audio data flow in an audio system design, the computer system comprising: an item inventory component configured to track information about audio devices that are connected to the audio system; a design store configured to store information about components in the audio system design and one or more relationships between components; an audio processing engine configured to simulate behavior of the audio system, wherein the audio processing engine invokes each of the components in the audio system design during simulation to process audio signals; a connect injector component configured to insert one or more signal injectors into the audio system design, wherein each signal injector generates an audio test signal; and a process injector component configured to generate the audio test signal for each signal injector in the audio system design.

12. The system of claim 11 further comprising a user interface component 120 configured to provide a user interface through which a designer can view and modify the audio system design;

13. The system of claim 11 further comprising a disconnect injector component 170 configured to remove one or more signal injectors from the audio system design;

14. The system of claim 11 further comprising a device communication component 180 configured to communicate with audio devices connected through a network to the audio system.

15. A computer-readable storage medium encoded with instructions for controlling a computer system to simulate an audio system comprising multiple distributed components, by a method comprising: receiving an indication to start a simulation of the audio system; identifying a location within the audio system to insert a test signal; inserting a test signal in the simulation of the audio system at the identified location; propagating the test signal through one or more components connected to the identified location; and displaying results of the simulation in a user interface.

16. The computer-readable medium of claim 15 wherein identifying a location to insert a test signal comprises receiving a selection from a user of a wire between components.

17. The computer-readable medium of claim 15 wherein identifying a location to insert a test signal comprises receiving a selection from a user of a component pin.

18. The computer-readable medium of claim 15 wherein inserting a test signal comprises modifying an execution vector of audio system components to include execution of a signal injector component.

19. The computer-readable medium of claim 15 further comprising inserting a signal probe component in the simulation that displays audio data at a specified point in the audio system.

20. The computer-readable medium of claim 15 wherein propagating the test signal comprises writing the test signal to a buffer associated with an original source component.