OS/2 Enters the DSP Age

by Linden deCarmo

Digital Signal Processors (DSPs) have ushered in a new era of multimedia computing. Gone are the days when you had to purchase an external fax/modem, sound hardware. and digital telephone answering machine. Now, you can buy a single DSP-based device that can perform all of these functions. Although previous releases of OS/2 had minimal DSP support, it is the next version of OS/2, which lets hardware vendors exploit the power of OS/2 multimedia. This volume of The Developer Connection for OS/2 is the first place where you can get an overview of the new DSP foundation in OS/2, and take a glimpse at the rich DSP API to be incorporated into future OS/2 releases.

DSP Background

DSPs have one primary task - manipulate signals. This might sound trivial, but consider this: sound, video, and digital data all are signals. It now becomes clear that DSPs are useful multi-purpose devices. Unlike conventional hardware cards, which have pre-programmed chips, DSPs use software modules, called tasks, to instruct the signal processor what functions it should perform. Because these tasks are software components and not hardware chips, many DSPs are software upgradeable. An example is the IBM WindSurfer, which uses the MWave DSP. This component can be transformed from a 9600-baud modem to a 14400-baud modem with a very small piece of code.

To supervise tasks, DSP providers typically have an executable called a DSP manager. Most DSP managers have the following features in common: they load and unload signal processing modules, schedule tasks, manage resources, and provide an API for user-level applications. Because these activities can be quite complex, DSP managers usually have code that runs at both user level (to load and unload files) and supervisor level (to control the hardware).

Several DSP managers (such as IBM's MWave or AT&T's VCOS) also offer the ability to chain tasks to create special effects. For instance, you could pipe the output of a digital audio task into an equalization task and place the equalizer's output into a task which removes noise. Because the chaining of these effects is user-defineable, DSPs can change with the user's requirements. And, because DOS and DOS extenders cannot provide the multi-tasking support required to fully demonstrate the power of a DSP, vendors are increasingly turning towards OS/2 as a product differentiator.

Current Architecture

The version of Multimedia Presentation Manager/2, MMPM/2, that ships with OS/2 2.1 uses a robust, proven architecture called Audio Device Driver (AUDIODD). AUDIODD lets driver writers control audio attributes (such as volume, treble, and bass) and transfer buffers to and from the hardware. Audio buffers are sent to the device driver by the Audio Stream Handler (ADSH). ADSH simplifies writing an audio driver by controlling data flow, and communicating with the Sync-Stream Manager (SSM) to ensure that the audio stays synchronized. The audio device receives audio attribute settings from a user-level component called the Vendor Specific Driver (VSD). The VSD is responsible for handling state information, resource management, and communication with the user-level Amplifier-Mixer Media Control Interface driver.

Although this architecture is effective for devices such as a Sound Blaster or Pro Audio Spectrum, it cannot easily incorporate complex devices (such as AT&T VCOS DSP manager) because AUDIODD cannot support the 32-bit, user-level code required by a DSP manager.

Vendor Specific Driver to the Rescue

The use of portable OS/2 Media Control Interface to access multimedia devices makes it possible to completely change the underlying device driver interface without affecting the compatibility of Media Control Interface applications. For example, a new user-level hardware interface has been created called the Universal Vendor Specific Driver Interface. This interface can work in tandem with, or replace, the AUDIODD interface. It is intended primarily for vendors who have user-level DSP managers or who must perform file I/O in their driver (for example, a vendor who needs to access files for MIDI wave table synthesis). The VSD interface is simple (for example, an audio VSD can be implemented by supporting only ten messages) and can be divided into the following categories:

• Basic functions (open, close, and product information)
• Query device states
• Set device states
• Data transportation to and from the logical device
• Miscellaneous functions (capturing images, sending raw buffers to the device)

Like an AUDIODD driver, each VSD receives data transportation commands from ADSH and device control commands from the Amplifier-Mixer Media Control Interface driver. However, two essential differences exist:

• The VSD is actually part of the logical mixer Media Control Interface device. To explain, the Media Control Interface mixer device performs only device-independent actions (such as process flags and accept commands). All device-dependent actions, such as volume manipulation, are forwarded directly to the VSD. As a result, the VSD interface offers vendors the ability to implement their own mixer device; a capability that is not possible with the AUDIODD architecture.
• VSDs have the ability to perform their own resource management by communicating with the Media Device Manager (MDM). When a VSD realizes that resource use on the DSP has changed, it informs MDM, and MDM removes (or adds) programs that are using the DSP. This resource management scheme (which is unique to OS/2) allows virtually an unlimited number of multimedia applications use the hardware and is a primary reasons why OS/2 is a showcase environment for DSP vendors.

Figure 1. VSD Architecture. All communication with the hardware is accomplished through the VSD. The Amplifier/Mixer Media Control Driver issue data control commands (open, close, set) and the stream handlers issue data transportation commands (read or write).

Hardware vendors must realize that if they do not have a DSP manager or other user-level code to write the existing AUDIODD interface is a better choice for their device. In addition, if you choose to write a VSD for your DSP, all existing device driver certification tests in the Device Driver Source Kit will run unchanged because these tests use the device independent Media Control Interface or Stream Programming Interface (SPI).

Table 1. A list of the advantages/disadvantages of the VSD and AUDIODD interfaces, respectively.

Function	VSD	AUDIODD
Supports user-level APIs (DSP manager)	Yes	No
Supports user-level functions (file manipulation)	Yes	No
Requires only protect-mode (or device driver) code	No	Yes
Works with OS/2 2.1	No	Yes
Works with future OS/2 versions	Yes	Yes
Supports 32-bit code	Yes	No (1)
Template code available	Yes	Yes
Requires additional device driver	Yes (2)	No
Allows creation of hardware-specific mixer	Yes	No (3)
Supports resource management	Yes	No
Compatible with all MMPM programs	Yes	Yes

1. It is possible to write 32-bit device driver code for OS/2 2.1, but it requires some work.
2. User-level VSD requires physical device driver to access the hardware under all circumstances.
3. AUDIODD only allows vendors to use the mixer interface it defines.

Peek Into the Future of OS/2 and DSPs

VSDs (through the Media Control Interface) give every OS/2 programmer access to the power of a digital signal processor. This power will be further enhanced when device connection support is fully implemented in a future OS/2 release. To explain: MMPM/2 is the only multimedia architecture with the notion of logical software connections between devices. A logical software connection lets the output of one Media Control Interface driver to be connected (or routed) to any other Media Control Interface driver. Unfortunately, new MMPM/2 programmers quickly become disappointed when they discover that the current version of MMPM/2 has rigid connectors (that is, the logical devices connect themselves to a specific Amp-mixer and do not allow this connection to be broken). Fortunately, this limitation will be removed, and programmers will be able to connect numerous DSP tasks (both software and hardware) together and perform effects impossible under any other environment.

Figure 2. Connection Architecture. Under a connection model that exploits DSP, a CD Media Control Interface driver could be connected to an equalizer Media Control Interface driver and the equalizer connected to the Amp-mixer Media Control Interface driver.

Future volumes of The Developer Connection News will discuss how connectors will be enhanced and how they offers device-independent DSP programming to each OS/2 multimedia enthusiast.

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation