With the DSP Resource Manager, Chicago offers both developers and users easy entry to DSP-based devices
Andrew W. Davis
Chicago promises many new features and benefits, but none will have a more dramatic effect on multimedia and business communications than Chicago's new DSP (digital signal processor) architecture. Its key components are a new layer of code dubbed the DSPRM (DSP Resource Manager) and two new DSP programming interfaces. These interfaces will shield applications software from hardware details and make it more attractive for independent hardware and software vendors to offer DSP-aware products.
Users will benefit from a new class of easier-to-use, higher-performance, and multipurpose audio, telephony, and multimedia devices. While the new DSP architecture will appea
r for the first time with the release of Chicago, Microsoft is clearly targeting the new DSPRM for other Microsoft operating systems as well, including Windows NT.
Any future-oriented, PC-based DSP architecture is directed toward general-purpose, programmable (RAM-based) DSP chips. These chips are true multimedia coprocessors that can run their own multitasking operating systems. Using a DSP coprocessor with its own real-time operating system has obvious performance advantages when running multiple simultaneous applications under Chicago.
But the Microsoft DSP specification is also compatible with dedicated hard-wired (ROM-based) DSPs, such as modem chip sets and sound chips, as well as with signal processing done on the host processor. Host-based signal processing is likely to become more important as the new Pentium and PowerPC chips gain market share. These processors are fast enough to provide some level of real-time response for multimedia applications, or they have embedded DSP capabilitie
s. Host-based signal processing is likely to be favored for entry-level systems where low cost is the primary design goal.
One purpose of the DSP architecture is to enable the DSP to carry out several operations simultaneously, servicing multiple concurrent processes, such as audio and fax, on the host. Because the processes on the host may be totally independent, the DSPRM must handle a wide variety of resource contention conditions. The DSP architecture does this by providing tools to handle resource allocation and prioritization of service requests.
Signal Processing, Chicago Style
At the top layer of the Chicago DSP architecture are the applications (see the figure ``The Microsoft DSP Architecture''). At the bottom are service providers, the hardware and device drivers that actually do the work. In between is a layer of middle-code, which Microsoft owns and controls. The middle-code, which creates an environment for standards, passes off commands from above to resources down below. In
this case, the middle-code is the DSPRM. The interface between the middle-code and the bottom layers is known generically as an SPI (service provider interface); Microsoft calls it the platform-driver interface. The DSPRMI (DSP Resource Manager interface) is the API. The layered structure provides signal-processing services to Windows device drivers while making the low-level DSP-hardware details invisible to high-level software applications.
Windows APIs commonly abstract the hardware details from applications such as word processors or communications software. For example, TAPI (Telephony API) supports telephony devices, Wave controls waveform file I/O for speech and music applications, and a Communications API supports fax. The APIs, in turn, communicate with DLLs, which interface to Windows device drivers residing in a hardware-specific layer called the DDI (device-driver interface). A device driver operates an I/O device by mapping hardware-independent API calls to a particular hardware architectu
re. Hence, each board vendor needs to provide DDIs for its product.
Under Windows 3.1, DDIs communicate with add-in products over the PC bus, but for Chicago, all DDIs are supposed to go through the resource-manager layer first and then to the platform driver, which is also hardware-specific.
Under Chicago, adapting a motherboard or add-in card for signal processing will involve three steps. First, you must write a platform driver. Second, you must create a library of platform nodes or DSP nodes that the Windows device drivers can use. The DSP chip vendors typically provide these, though in many cases, they are also available from independent DSP technology houses. Finally, you must write a Windows device driver for the new platform.
The Platform Driver
The platform driver is a Chicago Plug and Play driver that manages the physical link between host and platform. This driver contains the details of the platform's implementation such as DSP hardware, DSP operating system, hardware in
terface, and I/O devices. It hides these details from the Resource Manager and Windows device drivers. The driver implements the platform-specific functions for managing hardware resources (including memory) and dynamically loading nodes, including host-DSP communications, interrupt handling, I/O techniques, and communications with the DSP system software. The extent to which a platform driver must be involved in other aspects of the DSP operation, such as node creation and control, depends on the type of DSP and DSP operating system used.
A platform driver is a dynamically loaded VxD (virtual device driver) that specifies the DSPRM as its device loader. Because Windows is a multitasking environment, platform drivers are required to be reentrant. The platform driver and not the DSPRM determines support for multiple platforms in one system. Because you can load Windows VxDs only once, platform drivers should be able to accommodate multiple platforms of the same type. Similarly, the Windows device driver
s must also handle multiple platforms.
Multiple DSP implementations are likely to fall into one of two categories: single or multiple platform. A single-platform driver would present the illusion of a single powerful DSP to the DSPRM, although the hardware consists of multiple DSPs. A multiple-platform driver recognizes that different DSPs are available, such as one for audio services and a separate DSP architecture for video compression/decompression.
The platform driver runs the DSP code. The Microsoft specification does not attempt to standardize DSP code, which is typically stored in a library or database of images and information. The code is also specific to the DSP chip used. To meet Microsoft's minimum specifications, the platform driver must supply three abstract interfaces to the Resource Manager: stream I/O, message I/O (events), and node control.
Nodes
DSP nodes are the code that the DSP runs to process requests by Windows device drivers or service providers. Node refers
to entities that can be logically interconnected to perform operations and that the client device drivers can access. A node can be a task, an I/O thread, a device (e.g., a stereo codec), or a combination of elements. The code sets for data/fax modem, wavetable synthesis, and speech compression are all nodes. Nodes can reside anywhere. The platform driver must determine if the node resides on the DSP-based hardware platform or if it will have host-based components.
Nodes are typically stored in node libraries where the DSPRM accesses them. When a platform driver receives a request, it retrieves an image of that node's DSP machine code and downloads it to the platform for execution. The node library contains important node-specific information, including the DSP (or host) machine code and initialization data, the resource requirements for the node (i.e., memory, I/O, and processor time), and node attributes. Node images in the library are indexed by a platform global identifier and by a type so that on
e library can contain any number of nodes for any number of platforms. Hence, you can use the same node type on different platforms if the node has the same function, inputs, and outputs and if it understands the same message (e.g., a Hayes AT modem command set). This architecture will enable independent algorithm developers to make a standard set of nodes work on many platforms.
Each node is tagged with three attributes: real time or not real time, evictable or not evictable, and service class. All nodes in each real-time group compete with each other for DSP attention. The attributes provide a smooth way for the DSPRM to work with the platform driver and handle overload situations. Real-time nodes get priority over nonreal-time nodes. Microsoft assumes that simultaneous real-time nodes can work cooperatively if the system resources are sufficient for all nodes to perform their functions.
The evictable flag and service-class designations let the DSPRM prioritize task loading and eviction. The D
SP operating system, however, actually handles the implementation. When a resource conflict occurs, the DSPRM can halt and discard a node marked evictable. An executing node marked not evictable will not be subject to prioritized eviction. Service classes, which include telephony, modem, and games, are prioritized either by default or at run time by an application such as a Control Panel. In this way, you could designate that the ``receive fax'' function should take precedence over audio playback but that audio playback is a higher priority than image decompression during a multimedia presentation. Only the real-time attribute flag is visible to the platform driver itself.
A platform driver has two classes of resources available to it: single items, which are typically devices either allocated or not allocated, and countable items, such as memory that can be allocated up to some fixed limit. The platform driver communicates resource capacities and usage to the DSPRM, which acts accordingly.
For
example, when a request is made to allocate a node, the DSPRM makes the request of the platform driver. If that request fails due to insufficient resources, the DSPRM invokes prioritized node eviction. If the resource conflict includes a device that only one application can use at a time, the DSPRM identifies the nodes in conflict; if all are of equal or higher priority, it fails the allocation request. The DSPRM scans the node list, beginning with the lowest-priority service class. It then identifies and discards evictable nodes until enough resources are collected to satisfy the request. If it cannot free enough resources, the allocation request fails.
The query test for evictable nodes allows the platform driver and clients to override the eviction. More important, the query gives either the platform driver or the client an opportunity to modify tasks running on the platform to reduce resource requirements (e.g., stepping down a modem to 2400 bps).
Node eviction priorities are not always stat
ic. A node's real-time attribute may vary. If a task requires real-time response, then all nodes that make up the task are so marked, including nodes previously marked not real time. In addition, while service class is a static attribute (a modem is a modem), service-class priority is a run-time attribute, and you can change class priorities to meet changing needs.
The DSPRM
The Windows device driver for any specific hardware platform supplies Windows with logical device support, such as Wave In and Wave Out, by directing the DSPRM to load the appropriate nodes for the platform and then sending the appropriate data to those nodes. In many cases, the Windows device driver is platform-specific, because the driver is responsible for knowing which algorithms and interconnections are required on the platform to provide a desired service. Long term, however, it is possible that standard node libraries will exist that will let many device drivers become device-independent.
Just as Windows is a co
mpatibility layer between applications and devices, the DSPRM is a compatibility layer between drivers and the DSP. The DSPRM resides immediately below the Windows device-driver layer and provides access to the DSP. The DSPRM standardizes the data flow and control without knowing the meaning of the data or how it is transferred. Drivers can communicate without knowing about the details of the transfers, the hardware, or the DSP software. For example, an application can request a V.32 modem and receive the appropriate services without knowing how the services are provided.
The DSPRM core code is implemented as a VxD under Chicago. The DSPRM, which is a nonreplaceable component, is a Plug and Play device loader that gets loaded when the Virtual Machine Manager starts (see the figure ``The DSP Resource Manager and Its Interfaces'' on page 154).
The top interface to the DSPRM is the DSPRMI, which is organized as eight OLE 2.0 Component Object Models available to 16- and 32-bit device drivers and ser
vice providers and 32-bit applications. Ring 0 access to the DSPRM is provided by a separate VxD service interface (see the text box ``Virtual Device Driver Services'' on page 156).
The platform driver interface contains four sets of COMs (Common Object Models) that map to comparable modules (with confusingly similar names) in the DSPRMI: ISPPlatformDriver Interface, ISPPDAdvise Interface, ISPPDNode Interface, and ISPPNNodeAdvise Interface. The DSPRM turns DSPRMI function calls over to the platform driver through the platform-driver interface. For example, a device driver does not call a platform driver directly; instead, it would use the ISPPlatform::AllocateNode function in the DSPRMI. This function call allocates a node on the signal-processing platform. The Resource Manager would then use the platform-driver interface ISPPlatformDriver::AllocateNode, which allocates all resources required to run a node. The platform driver itself retrieves the node and attempts to grab the needed CPU, memory, and I
/O devices (see the figure ``Interfaces to the DSP System Objects'').
The DSP Platform
The bottom layers in the Chicago architecture make up the DSP hardware and chip-specific software, such as the DSP operating system (if present) and DSPs for functions such as speech compression, imaging, and modem modulations--the signal-processing services delivered to the higher levels. The DSP hardware intended for most Chicago applications includes a multipurpose, multitasking processor with its own peripherals and local memory. The DSP chip, or chips, are under the control of a real-time operating-system kernel executing on the DSP. The operating system makes calls to a variety of multimedia libraries and uses DSP device drivers for I/O functions such as telephony and audio. Suitable DSPs from Analog Devices, AT&T, IBM, Motorola, and Texas Instruments are already available.
Microsoft also calls out several desired features of the DSP operating system. These include the ability to run more than one
thread of execution, which gives the system the appearance of doing many things concurrently. The DSP operating system must also provide hooks to handle real-time features, since many of the multimedia signals require real-time responses. How these features are achieved is independent of the Microsoft architecture. For example, AT&T's VCOS (frame-based), IBM's Mwave (deadline-based), and Spectron's SPOX (priority-based) all provide concurrency and real-time scheduling but use different technical approaches.
Industry Response
AT&T and IBM have been providing comprehensive DSP hardware and software solutions for Windows 3.1, and both companies have committed to making their architectures comply with the Chicago standards. AT&T's DSP solution centers around the DSP32XX chip family and VCOS; IBM has the Mwave chip and the Mwave operating system. Each company controls its own hardware and DSP software and offers a multitasking operating system with an integrated Resource Manager. For instance, VCOS in
cludes the operating-system kernel for the DSP chip and a host-based applications server and Resource Manager, code that predates the DSPRM. AT&T and IBM will redesign certain pieces to move them from ring 3 (Windows 3.1) to ring 0 for Chicago and have these pieces bolt cleanly to the new architecture. Both companies already have customers with products similar to Microsoft's platform specification.
The AT&T host code centers on the VCAS/VRM (VCOS Application Server/VCOS Resource Manager), which are constant for all AT&T's customers (see the figure ``AT&T's VCOS/DSPRMI Architecture for Chicago'' on page 160). These serve as a mapping layer from Microsoft's DSPRM to a hardware abstraction layer, which AT&T calls the VE. The VE is nearly the only code that is hardware-dependent. The VCAS layer translates Microsoft's node-allocation methods to frame-based commands that the VCOS kernel can handle, while the VE understands, for example, that the hardware has one, two, or four DSP chips, each with its own I/
O port, on an ISA bus board with local memory or on a PCI (Peripheral Component Interconnect) board with bus-mastering capabilities. The VRM keeps track of resource availability and allocations. For example, VRM knows that two telephone lines but only one speaker are available. It also knows that device driver YY is currently attached to the speaker and that DSP 2 is less loaded than DSP 1.
A DLL stub in ring 3 provides the transition hook to ring 0. The stub also works in reverse and offers disk I/O services to ring 0, which has no file-service capabilities. IBM Mwave has a similar structure.
AT&T has already developed a suite of device drivers for Wave, MIDI, Mixer, and TAPI. ACM audio compression and speech are under development. Under Chicago, these drivers can continue to use the existing interfaces. They are compatible with Chicago but don't use the DSPRM services. Alternatively, in the future, if AT&T or its customers modify these drivers, the drivers can be made to go through the DSPRM l
ayer.
Microsoft's Platform Specification
With the DSPRM, Microsoft has simultaneously published a DSP Architecture PFS (Platform Functional Specification), which describes recommended and minimum platforms and functions (see the figure ``DSP ISA Adapter Architecture''). The table represents what Microsoft believes will be needed to run standard classes of applications in the areas of audio, telephony, and communications. The PFS provides a specific example of a hardware implementation that will enable Plug and Play computer telephony integration and function with standard Windows APIs, multimedia APIs, TAPI, and the new speech APIs. The PFS also provides architectural details for an example implementation of the recommended platform. Microsoft will provide design information and driver source code in the DSP platform SDK (Software Development Kit).
By publishing the PFS, Microsoft is establishing a de facto standard multimedia peripheral. It defines a playing field that includes a programm
able DSP, RAM, 16-bit stereo codec, Windows Sound System-compatible mixer, wavetable synthesis ROM, two analog phone-line connections, phone head-set connection, CD-ROM interface, Plug and Play support, multichannel DMA control, and two 16-bit ISA data channels. Applications developers can write code to take advantage of the functionality described in the PDS with reasonable confidence that hardware vendors will be providing such a device.
Global Benefits
One benefit of a layered architecture is that structure and divisions of labor are well understood. In the current signal-processing market, there is no clear division between what the applications vendor and the signal-processing vendor must do. Hence, most systems are complete packaged hardware/software solutions. The Microsoft DSPRM architecture will offer structure to the market by requiring that the platform definition and base set of capabilities be well designed and meet defined programming interfaces.
If the industry adopts Micros
oft's architecture as a standard, vendors will be able to build the DSP-enabled systems that customers require. DSP providers will be able to create subsystems that meet compatibility standards and that can take advantage of third-party applications. And end users will find a broad range of compatible products meeting a range of price/performance needs. Just as Microsoft Windows helped allow CAD software vendors to provide a common driver for the many different PC display systems, the DSPRM will buffer multimedia and communications software vendors from the many emerging DSP solutions.
Microsoft's Minimum And Recommended DSP Functionality
MINIMUM RECOMMENDED
Plug and Play Not required Full support
Wave record and playback 11.025 and 22.05 kHz, 5.125 to 48 kHz, mono,
8-bit PCM 8-bit pulse-code stereo,
and 16-bit modulation
Music synthesis MIDI Wavetable
Telephone interface One line: POTS or ISDN Two lines: POTS or ISDN
CD-ROM interface Not required One interface, internal
or external, IDE or SCSI
Games compatibility Not required Compatibility with Sound
Blaster, AD1848, MPU-401,
and Adlib
Call types Voice only Voice, data, fax,
and VoiceView
Telephony DTMF generation and DTMF generation and
detection, CallerID, detection, CallerID,
and popular Class and Class features
features
Data communications Not required
V.18, V.17, V.29, V.21,
Channel 2, and V.27 ter
VoiceView Not required Full support
Multimedia devices Telephone set (wave), Telephone set (wave),
telephone line (wave), telephone line (wave),
audio codec (wave), audio codec (wave),
line in (AUX), and mixer synthesis DAC (MIDI),
line in (AUX), and mixer
Figure: The Microsoft DSP Architecture
Chicago's DSP architecture is centered on Microsoft's DSP Resource Manager code layer. Vendors who wish to take advantage of the architecture need to provide Windows device drivers that are compatible with the DSPRMI, a new API, and platform drivers that are compatible with the SPI (service provider interface), called the platform driver interface. High-level applications will generally use standard Windo
ws APIs for telephony and multimedia, but for cases where the APIs do not yet exist, the applications may call the DSPRM directly.
Figure: The DSP Resource Manager and Its Interfaces
The DSP Resource Manager is a VxD itself. The DSPRM offers 16- and 32-bit interfaces to Windows device drivers and a ring 0 interface to other ring 0 VxDs (e.g., Microsoft's Sound Blaster emulator). The ring 0 interface improves performance by eliminating the need for multiple ring transitions.
Figure: Interfaces to the DSP System Objects
Device drivers obtain their platform identification during load time because drivers are associated with a particular device on a specific platform. Thus, drivers may use the ISPManager::SelectPlatform method directly. ISPManager provides services to select a DSP platform, advise the system of DSP events, and make use of the node library. ISPPlatform is a set of routines to create nodes on the platform, perform I/O between nodes, obtain the current state
of the platform, and register to receive notification about events on the platform. ISPNode contains the methods to send data to and from a particular node. Data movements are reported asynchronously to a calling thread so that other processing may proceed during the transfer of data to and from a physical device. ISPNode also contains methods for allocating nodes by groups and having them execute at once. IEnumSPPlatform and IEnumSPNode modules allow applications to find out what class of services or nodes are available and to select services based on a category level. The three object modules ISPMgrAdvise, ISPPlatAdvise, and ISPNodeAdvise are two-way interfaces that either the client or the caller implements; advisement interfaces provide calls to communicate platform and node status to the rest of the system asynchronously.
Figure: AT&T's VCOS/DSPRMI Architecture for Chicago
AT&T is restructuring its DSP3210/VCOS solution for the new Chicago architecture. Certain functionality has be
en moved from ring 3 to ring 0. The diagram shows a software structure that attaches cleanly to the Microsoft DSPRM but still provides added features. AT&T's VCAS and VRM map from Microsoft's DSPRM and a standard VCOS platform driver layer to a hardware abstraction layer that contains all the product-specific code. The VRM code running on the host keeps track of both DSP and I/O resources and usage levels and can balance loads across multiple DSPs.
Figure: DSP ISA Adapter Architecture
Microsoft's Platform Function Specification provides architectural details for an example implementation of the recommended Microsoft DSP architecture platform. Design information and driver source code will be provided in the DSP Architecture Platform Development Kit for this example implementation. The POTS version (analog telephone lines) is unusual in that it includes two separate phone interfaces, as well as a stereo I/O sound system with wavetable synthesis and a CD-ROM interface. Performing all these
functions concurrently will be a formidable challenge to today's DSP chips.
Andrew W. Davis is an independent marketing consultant in Southborough, Massachusetts, focusing on high-technology business development and marketing communications. You can reach him on the Internet at
andrewwd@aol.com
or on BIX c/o ``editors.''
Windows Becomes DSP-Aware
