|The Eleventh Annual Interactive
PROJECT BAR-B-Q 2006
Group Report: Ensuring that PC Audio Editing/Rendering Plug-ins and Processors Always Work
|Participants: A.K.A "Prug and Pray"|
Gary E. Johnson, SMSC Austin
|Len Layton, C-Media Electronics|
|Keith Weiner, DiamondWare||Benjamin Masse, Double V3|
|Peter Lupini, 3dB Research Ltd.||Trenton Henry, SigmaTel|
|Facilitator: Van Webster; Webster Communications|
Today’s PC-based Audio Editing / Rendering equipment doesn’t always work well, especially with plug-ins, and can be more expensive than necessary due to piracy. In a complex computer environment, a broad range of tasks compete for CPU time causing glitches, latency and delays. We will propose a potential solution to multitasking demands in a PC environment.
Specific problems to be addressed:
The model for our solution approach is the analog world rack mount outboard processors and patch bays. In these systems, each processor (i.e. UREI 1176) is a self-contained, fully functional unit that operates independently of the host mixing console. The unifying properties of the device are its audio interconnections, physical mounting and AC power connection. Applying the same principal to plug-ins and audio processing, we propose to define a combination of packing, goesinto, goesouta, control and powering that can be modularly implemented across a wide range of applications. The core concept is that the application includes its own processing power and is not CPU dependent for operations.
With “It Just Works”, we propose dedicated, module-based processing units, similar in scale to a compact flash card, containing the software, processing capability, control communications inputs, outputs, timing and power connections. As hardware solution, this approach protects both the application IP and provides a known working product. The modules include full rendering capable signal processing so the PC is not required for any signal processing at all. The modules are shipped with software PC-based Graphical User Interface (GUI) for control.
It Just Works; small format; mini version of 19” rack concept with standard backplane; protects applications from copying; guaranteed interoperability; signal processing on modules; markets could be expanded beyond audio to photos, video, graphics, etc.
Examples of modules include the main application (Pro Tools, SonicFoundry, Acid, etc.); plug-ins for such applications (reverb, eq, mixing, scaling, etc.), DSP for loudspeaker compensation and spacialization. The control and signal interfaces will be standardized so any unit will interoperate with any other.
Review the concepts with industry participants, particularly Line 6, Sony and Cakewalk. Keith, Gary and Van to identify industry key sponsor.
If concept is feasible, an open group would then need to determine the
specifications. BBQ reflector.
Expanded Problem Statement:
Plug-ins and audio processing all depend on the use of a central CPU which is burdened with a wide range of tasks, both specific and general. While there are options to prioritize the housekeeping tasks, implementing the options is tedious and often incomplete. In complex audio applications, the insertion of plug-ins and mixing functions can overload the CPU. There are also incompatibilities between audio application programs that interfere with the operation of processes on a cross application basis.
The goal of a solution of this problem is to insure that plug-ins and
other processors always work and that the burden of processing be reduced
on the CPU by dedicating outboard processing power to each specific application.
The proposed solution is to create an outboard software and hardware modular packaging, bussing and interface that will combine all the functions needed to implement an application, independently of the host CPU. Because each modular package is functionally self contained the interconnections can be summarized as goesinto, goesouta, control, timing and power. Each module would contain the software, and processing necessary to accomplish the application. By optimizing the processing capability to the task at hand and operating in parallel with the CPU and other modular units, computer capacity can be increased without replacing the CPU and conflicts within the operating system can be avoided.
The form factor of each module is a single plug in card with scalable dimensions. Given a common connecting scheme and physical mounting, cards could be constructed in varying sizes including alternatives for length and multiple layers. The docking hardware could be an outboard device, similar in size to an AC plug strip, slots in a host piece of hardware, or an internally located, non-user changeable mounting.
An additional benefit of this hardware/software-based approach is to reduce the likelihood of incidental piracy and unauthorized copying. As the software and hardware are a matched set, casual copying is unlikely and mass piracy is prohibitively expensive. There could be a version of the product that would permit software upgrades to existing hardware.
Pro audio and musical applications can include all of the types of processing currently implemented in VST and similar software, mixing applications. Semi-virtual synthesizers and loudspeaker DSP could all be implemented in this system. Multi-plug outboard buss systems could be used for audio applications using PC’s of any flavor as controllers. Plug-in slots could be included in keyboards, amplifiers and other musical instruments to apply custom processing of the user’s choice, controlled by hardware knobs and/or small scale LCD screens with menu implementation.
Mass market CE applications may be essential to establish the production volume necessary to attract chip manufacturers to this product category. There is also a growing capacity with overseas manufacturers to produce custom chips in low volume at a reasonable price point. Some mass-market applications could include loudspeaker compensating DSP for consumer sound systems. Receivers and other audio devices could include a slot for a processor matched to a specific set of speakers. Each speaker system would come with its own card for field installation. Other applications could be dedicated processing for mobile devices, automotive sound and workspace environments.
We further feel that this infrastructure could be applied to non-audio applications including video editing, special effects, graphics and photographic manipulations. Self contained computing modules may also be applicable to other commercial and business applications. Medical equipment is a likely candidate for this packaging scheme. Machine control and automation are possible. Industrial testing and measurement could find this approach to applications commercially viable.
Other reference material:
“A Freely Configurable Audio-Mixing Engine with Automatic Loadbalancing”, M. Rosenthal, M. Klebl, A. Gunzinger, G. Troster; Electronics Laboratory, Swiss Federal Institute of Technology, March 7, 1995
“Automatic Reconfiguration of a Digital Audio Mixing Engine”, M. Rosenthal, P. Kohler, A. Gunzinger; Electronics Laboratory, Swiss Federal Institute of Technology
32-bit (integer? Floating point?) 48kHz linear PCM is sufficient resolution for now and forever due to human limitations (validate with group). Avoid accumulating round-off errors.
If this is so, then a given card needs only N times ~3Mbps bandwidth (N = number of simultaneous channels).
Key concept: The bus should be switched fabric where bandwidth to each
card is independent of others
Each card has a DSP and real-time OS.
Kinds of functions:
Each card reports:
Cards must be dynamically discovered.
A generic user interface should be able to present a screen to control all parameters for each function (GUID could allow manufacturer to find its specific hardware and provide a better plug-in for a complex function like reverb).
The design must define data format (e.g. RTP?) number of channels, number of samples, sample rate, etc. Should a block be able to constrain the system (e.g. don’t give me < 1000 samples or > 2000 samples)?
PC runs user interface. Alternative, small touch panel, remote control UI on TV (for home theater receivers), etc.
Interesting problem: a speed-changer function provides output samples at a different rate than it consumes them. Buffering doesn’t solve if consumption is faster than production. Also finite buffer size would overflow eventually. Solution: traverse chain from sink to source and query: to product Y samples of output, how many samples of input do you need?
KW/DiamondWare will put some code into the pool if this becomes real.
select a section:
Copyright 2000-2014, Fat Labs, Inc., ALL RIGHTS RESERVED