WDM Audio Drivers Overview

Windows Driver Model (WDM) audio drivers make use of the kernel streaming (KS) components, which operate in kernel mode and are part of the operating system.

Hardware vendors should make several design decisions before beginning development of a Windows-based audio hardware device.

The first decision is whether to design an audio device that requires a vendor-supplied custom driver. Windows contains operating-system support for PCI, USB, and IEEE 1394 devices that conform to the Microsoft Universal Audio Architecture (UAA) guidelines. The vendor does not need to provide a custom driver for a UAA-compatible audio device.

However, if a vendor-supplied custom audio driver is necessary, the vendor must choose whether the driver should be designed to work in conjunction with the PortCls system driver (Portcls.sys) or the AVStream class system driver (Ks.sys). Both PortCls and AVStream are part of the Windows operating system. PortCls is the correct choice for most audio adapters. For more information about PortCls, see Introduction to Port Class. For more information about AVStream, see AVStream Overview.

When designing a custom adapter driver that uses PortCls, the devices on the audio adapter are made available to applications using WaveRT. For more information, see Introducing the WaveRT Port Driver.

Two additional decisions involve how to present the adapter topology and pin data ranges to audio applications. The topology is a logical map of the data paths and control nodes in the adapter circuitry. The data ranges specify the data formats that the devices can support in their wave and MIDI streams. Both decisions affect how the devices on the audio adapter appear to applications.

In making all of the previously mentioned decisions, the hardware vendor must weigh the value of performance enhancements against the cost of implementing them. Another consideration is whether a particular solution can be made to work on a number of products in the Windows family. This section provides an overview of these issues as well as references to more detailed documentation about specific topics.

This section includes the following topics:

WDM Audio Terminology

This section describes the differences in terminology between the Microsoft Windows Driver Model (WDM) audio driver architecture and the generic Windows layered driver architecture. The generic driver architecture is exemplified by SCSI port/miniport drivers (see Storage Driver Architecture).

The terms defined by the generic and WDM audio driver architectures are similar, but they do have some important differences, as described below.

Miniport Driver (Generic)

The miniport driver (generic) is the hardware-specific driver for an adapter that resides on a system bus (for example, PCI or ISA). This driver has a single entry point, DriverEntry, and registers a table of functions with a port driver. This table of functions serves as the miniport driver’s upper-edge interface.

The miniport driver sits below the port driver in the driver stack. That is, all calls to the miniport driver are made from the port driver and all calls out of the miniport driver are to the port driver’s lower-edge interface.

The following figure illustrates the meaning of the terms stack, upper-edge interface, and lower-edge interface as they are used in this context. The block representing the port driver is stacked on top of the block representing the miniport driver. Hence, the miniport driver sits below the port driver in the «stack».

The port and miniport drivers communicate through the software interfaces that they expose to each other. In the preceding figure, these interfaces are associated with the lower-edge of the block representing the port driver and the upper-edge of the block representing the miniport driver. This representation is the source of the terms «lower-edge interface» and «upper-edge interface».

Port Driver (Generic)

The port driver (generic) surrounds a miniport driver.

The port driver:

Implements WDM streaming filters.

Provides a common interface to the rest of the operating system.

Handles I/O requests from the system and recasts these requests as calls into the miniport driver’s function table.

Provides the miniport driver with a library of support functions (the port driver’s lower-edge interface).

The port driver hides many of the details of the operating system from the miniport driver, and the miniport driver hides the specifics of the underlying hardware from the port driver. The implementation of the port driver might undergo changes for different operating system releases, but the port driver’s interface to the miniport driver remains more-or-less unchanged, enabling the miniport driver to be largely platform-independent.

Minidriver (Generic)

The minidriver (generic) represents a hardware component on a bus. The minidriver uses the bus driver to communicate to the physical device over the bus, and it binds together the bus driver and one or more class drivers.

Class drivers help the minidriver present the physical device to clients as a type of logical device. In WDM environments, a minidriver typically receives requests in IRP form from class drivers, and sends requests in IRP form to a bus driver.

A minidriver might also have to communicate with several class drivers. An example of a minidriver that binds to multiple class drivers is a minidriver for a CD-ROM drive on an IEEE 1394 bus. It might bind to a file-system driver so that the drive can be accessed from the file system. However, it also binds to a Redbook system driver so that audio can be streamed from CDs.

Bus Driver (Generic)

The bus driver (generic) gives minidrivers access to a physical bus. The Microsoft Windows hardware abstraction layer (HAL) is sometimes referred to as the system bus driver because it provides access to the system bus. For more information, see Bus Drivers.

Class Driver (Generic)

The class driver (generic) implements behavior that is common across a class of similar devices.

The class driver:

Eliminates duplication of functionality in hardware-specific drivers.

Is not bus-specific.

Is not aware of resource issues (for example, DMA and interrupts).

Miniport Driver (WDM Audio)

The miniport driver (WDM audio) implements a function-specific interface for a function on an audio adapter card that resides on a system bus. A miniport driver is a component of an adapter driver. It is not recognized as a driver by the operating system. In this regard, an audio miniport driver differs from a generic miniport driver.

Unlike generic miniport drivers, audio miniport drivers do not implement DriverEntry, are not registered, and do not rely entirely on their respective port drivers for support. Multiple audio miniport drivers that address multiple functions can be linked into a single adapter driver (and associated with a single device object).

Adapter Driver (WDM Audio)

The adapter driver (WDM audio) serves as a container for all miniport drivers associated with a given adapter. This adapter driver is recognized as a driver by the operating system and is contained in its own .sys file.

The audio adapter driver consists of a set of miniport drivers and additional code that addresses initialization issues. For example, an adapter driver implements a DriverEntry entry point.

Port Driver (WDM Audio)

The port driver (WDM audio) implements a KS filter on behalf of a miniport driver and operates in the context of a port class driver. The port driver exposes the miniport driver’s function-specific code as a KS filter to the system and is responsible for implementing adapter-independent functionality.

Unlike the generic port driver, the audio port driver shares the device object and is, therefore, instantiated differently. An audio port driver is also more closely resembles a generic class driver than it does a generic port driver in that it implements behavior that is expected of a class of devices (it is not bus-independent).

Port Class Driver (WDM Audio)

The port class driver (WDM audio) serves as a container for a collection of port drivers, each of which provides support for a different type of audio hardware function. The following figure shows the relationships between the audio port class and adapter drivers.

An adapter driver manages an adapter card that might contain several different hardware functions. As shown in the preceding figure, the adapter driver contains a miniport driver to manage each type of hardware function. Similarly, the port class driver is designed to provide support to adapter cards with multiple hardware functions. The port class driver provides a port driver for each of the well defined function types that it supports. The adapter driver binds its miniport driver for a particular function to the corresponding port driver for that function type. The port driver for each function handles communication with the WDM audio clients that use the function. The miniport driver contains all of the hardware-specific code for managing that function.

The port class driver (WDM audio) primarily functions as a container for multiple subdevices that are associated with a single device object. Bus drivers create a single physical device object (PDO) for each Plug and Play (PnP) node they enumerate.

In the case of an audio adapter, a single PnP node frequently contains multiple audio functions. To expose the various functions associated with a node as distinct devices typically requires writing a bus driver for the adapter. The bus driver enumerates the hardware functions and creates corresponding PDOs. In this scenario, one or more function-specific drivers need to bind to the PDOs and negotiate with the bus driver for access to shared resources on the adapter.

The port class driver uses the kernel streaming driver’s ability to expose various aspects of a single device object in order that the operating system recognizes the device as a set of distinct subdevices.

A reference string is appended to the device name to specify the desired subdevice. The kernel streaming driver dispatches creation IRPs based on this reference string. After a file object is created, the kernel streaming driver provides dispatching of IRPs that are targeted at the file object that represents the subdevice. In addition, the port class driver implements a COM-based model for packaging subdevices.

An adapter driver instantiates a port driver and a miniport driver and binds them together by passing a pointer to the miniport driver as a parameter to the port driver’s initialization function (see the code example in Subdevice Creation). The resulting port/miniport driver stack constitutes a KS filter that represents one of the subdevice types that the port class driver supports.

The port class driver’s PcRegisterSubdevice function registers the subdevice, which is perceived as a device by the rest of the system. The port driver receives creation IRPs targeted at the device object, but for only those IRPs that are specified by the reference string under which the subdevice is registered. The port driver also receives the IRPs targeted at the file objects that are associated with the subdevice. The port driver is responsible for the subdevice’s behavior as a KS filter and for communicating appropriately with the miniport driver.

For more information about designing drivers for multifunction audio cards, see Multifunction Audio Devices.

Introduction to WDM Audio Drivers

Kernel streaming (KS) services support kernel-mode processing of data streams for audio and for other types of continuous media. Conceptually, a stream undergoes processing as it flows along a data path containing some number of processing nodes. A set of related nodes is grouped together to form a KS filter, which represents a more-or-less independent block of stream-processing functionality. More complex functions can be constructed in a modular way by cascading several filters together to form a filter graph.

A typical audio adapter card might contain audio devices for playing a wave stream through a set of speakers, converting the audio signal from a microphone to a wave stream, and synthesizing sound from a MIDI stream. The adapter driver can wrap each of these audio devices in a KS filter that it exposes to the operating system. The operating system connects the filters to other filters to form filter graphs that process audio streams on behalf of application programs.

KS filters are connected together through their pins. A pin on an audio filter can be thought of as an audio jack. A client instantiates an input or output pin on a filter when the client needs to route a data stream into or out of that filter. In some contexts, the terms pin and stream can be used interchangeably.

The output pin of the upstream filter is connected to the input pin of the downstream filter. The data stream from the output pin must have a data format that the input pin can accept. Data buffering is typically required to smooth out momentary mismatches in the rates at which an output pin produces data and an input pin consumes it.

A KS filter is implemented as a kernel-mode driver object that encapsulates some number of related stream-processing functions. The functionality can be implemented in software or in hardware. In this model, an audio adapter can be viewed as a collection of hardware devices, and the adapter driver exposes each of these devices to the audio system as an individual filter.

An adapter driver exposes a collection of filter factories to the audio system. Each filter factory is capable of instantiating filters of a particular type:

If the adapter contains one or more devices that are similar or identical in function, the driver groups the filters for those devices together into the same filter factory.

If the adapter contains several different types of devices, those devices are presented through several different filter factories.

A KS filter exposes a collection of pin factories to the audio system. Each pin factory is capable of instantiating pins of a particular type. If the filter can provide one or more pins that are similar or identical in function, the filter groups those pins together into the same pin factory. For example, a filter that performs audio mixing might have one pin factory that can instantiate a single output pin and a second pin factory that can instantiate several input pins.

KS services are built upon the Windows Driver Model. Note that the term KS filter must be distinguished from the term filter driver, which is another WDM concept. A filter driver resides in a WDM driver stack and can intercept and modify the I/O request packets (IRPs) that propagate through the stack. Upper- and lower-level filter drivers reside above and below the function driver, respectively. In this section, the term filter refers to a KS filter rather than a filter driver unless noted otherwise. For more information about filter drivers, see Types of WDM Drivers.

This section contains the following topics:

For updates and information about new features of the WDM audio architecture, see the audio technology website.