Status: WG Proposal (Closed, Uncompleted)

Source: Keith Weiner, DiamondWare

Date: July 1, 1999    

Background

       The software technology exists today to provide a wide array of audio signal processing functions from low-pass filters to effects like flange to compression and decompression of compute-intensive coding schemes. Hardware already exists to accelerate these functions and vastly improve quality. However, unless the application programmer is willing to learn and deal with proprietary and complex APIs and/or require non-standard hardware to be installed, he has no standardized way to apply a low-pass filter, flange, etc., to a sound stream.    

      For example on a Windows PC, there is no current DirectSound buffer property set solution (e.g. IDirectSound3Dbuffer, I3DL2 included) that can address the real problem: i.e. what if the programmer doesn't want to play the processed audio, but wants to save it to disk, compress and send it over the internet, etc.? Once audio is put in a DirectSound buffer, there is no longer any means of getting it back, after processing.       

Purpose and Goal of the DSP WG       

      The purpose of this WG is to enable applications to send real-time streams of audio to a DSP Filter for processing, and receive it back. The goal is to document, specify, standardize, and popularize an architecture and API to achieve the purpose.       

There are two considerations:       

• To keep it "open", i.e. without legal restrictions, royalties, patents, etc.       
• To be agnostic to hardware, software, and algorithm specifics wherever feasible    

      I do not want to emphasize the filters themselves, and certainly not how to name them, how to parametrize them, or how to compute them. The important part is an elegant and efficient API and architecture.    

Benefits:

       Hardware vendors, content providers, DSP algorithm developers, and tool developers all win. The market for this technology can be easily reach hundreds of millions of dollars in hardware, content, software, etc.       

• Hardware vendors will open a new market: the fixed-function DSP Filter accelerator       
• More immersive games, www sites, etc. obviously benefits consumers       
• A much wider market for DSP filter IP developers       
• Better quality filters which run in real-time and a wider market will grow the tools markets

Current State of the Industry:

      Some work needs to be done here (in fact, investigating various existing APIs will be the first order of business for the newly formed WG), but clearly there are existing products. We do not need to create a concept for a new kind of technology, or even a new kind of product category or market.       

      Already, programmable hardware products from TI, Motorola, Intel, Analog Devices have the power to provide varying degrees of DSP filtering for some number of audio streams.       

      Various proprietary DSP Filtering APIs (from DiamondWare, Microsoft, Steinberg, Digidesign, and others), having varying degrees of the required attributes (e.g. real-time, affordable, well known and supported, compute-efficient, etc.) have been identified.       

      A large and growing library of knowledge, IP, and code to perform audio filtering exists in the form of ActiveMovie filters, CoolEdit filters, etc.    

The Work:

       The work will be undertaken in several phases, proposed below:       

1. Phase 0 (logistical)       
   1. Who are the WG active participants?       
   2. When/where to meet? Email good enough?       
2. Phase 1 (preliminary)       
   1. Enumerate existing APIs and architectures for real-time DSP streaming       
   2. Determine criteria for acceptability       
   3. Either anoint an existing API for DSP, or else invoke Phase 2b       
3. Phase 2a (technical)       
   1. Enumerate standard filters and parameter sets       
   2. Explore and identify the problem space       
   3. Address "API's incompleteness problem", i.e. if a given implementation doesn't offer one feature       
   4. Address licensing issues, i.e. for software-only DSP Filter products       
4. Phase 2b (more technical)       
   1. Determine requirements
   2. Propose architecture which conforms       
   3. Specify an example implementation such as a Microsoft Windows Ring 3 API and a Microsoft Windows Ring 0 API (for hardware drivers) or other such examples as deemed appropriate by the group.       
5. Phase 3 (business)       
   1. How to bootstrap hardware market from near-0       
   2. How to get content developers, hardware vendors, and software technology companies to sign on       
   3. How to position the API in terms of the OS vendor, hardware, software companies, etc.-i.e. how to keep it "open" without orphaning it.
   4. Intellectual property rights

Examples:

       Here are some examples of applications which require the critical ability to not only send a digital audio stream to a DSP filter but to receive it back when done.       

• Wave Editor Program. A digital audio editing program sends a sound through one or more DSP filters and receives it back in order to store in a disk file.       
• Non-standard DSP last in chain. An application which uses interactive audio sends a sound through a variety of hardware-accelerated DSP filters and then, for the last stage, through its own proprietary filter.       
• An internet application. After DSP processing some voices, it mixes them, compresses the result, and sends it across the internet.    

      From these 3 examples, it's easy to see how, for example, the inability of the current DirectSound property set model to return a processed sound to the application makes it unsuitable as a general-purpose DSP architecture and API.