Plug and Play Guidelines for High Definition Audio Devices

Updated: October 12, 2004

This paper provides information about audio devices and drivers for the Microsoft Windows family of operating systems. It provides guidelines for providing Plug and Play support for audio devices that are compatible with the Intel High Definition Audio specification and meet the additional requirements of Microsoft's Universal Audio Architecture (UAA). As part of the UAA initiative, Microsoft provides a list of Plug and Play guidelines for identifying High Definition Audio codec and bus controller devices. These guidelines, which are presented in this document, allow an HD Audio device to be identified with greater precision than was possible with the Plug and Play device-identification system for AC'97 devices. By following these guidelines, hardware and system vendors can provide an improved user experience by more accurately identifying the HD Audio devices in the system and ensuring that the Plug and Play manager has the information it needs to load the appropriate drivers for those devices.

This information applies for the following operating systems:
Microsoft Windows Vista
Microsoft Windows Server 2003
Microsoft Windows XP
Microsoft Windows 2000

Future versions of this preview information will be provided in the Windows Driver Kit (WDK).

 Download this paper in Microsoft Word [200 KB]

On This Page

  Introduction
  HD Audio Bus Controllers
  HD Audio Codecs
  INF Files for HD Audio Codecs
  References

Introduction

This document provides information about audio devices and drivers for the Windows family of operating systems.

As part of its Universal Audio Architecture (UAA) initiative, Microsoft has developed a set of Plug and Play guidelines for identifying High Definition (HD) Audio codec and bus controller devices. These guidelines, which are presented in this document, allow an HD Audio device to be identified with greater precision than was possible with the Plug and Play device-identification system for AC'97 devices.

In Windows Vista, Microsoft will include UAA driver support for HD Audio codec and bus controller devices that meet the UAA requirements. In addition, Microsoft will provide versions of these UAA drivers that can be installed in Windows 2000, Windows XP, and Windows Server 2003.

UAA-compatible HD Audio devices can rely entirely on the operating system for driver support. Alternately, if a hardware vendor sells an HD Audio device that is UAA-compatible, but wants to provide value-added features that are not supported by the UAA class drivers, the vendor can supply a custom function driver to enable these features.

By following the Plug and Play guidelines in this document, hardware and system vendors can provide an improved user experience by more accurately identifying the HD Audio devices in the system and ensuring that the Plug and Play manager has the information it needs to load the appropriate drivers for those devices.

Improved device identification helps to prevent the loading of an inappropriate driver that might make use of an HD Audio device difficult or impossible, or that might prevent certain hardware features from functioning correctly. System vendors have the option of providing custom drivers to enable value-added features that might be available only on a specific set of system configurations. Through their INF files, vendors can identify precisely which systems require custom driver support. For all other systems, they can rely entirely on the operating system for driver support.

The following sections present guidelines for incorporating Plug and Play support into HD Audio bus controllers and codecs, and for specifying Plug and Play information in the INF files that install HD Audio devices.

 Top of page

HD Audio Bus Controllers

HD Audio bus controllers are identified by their class ID. Providing additional Plug and Play information for an HD Audio controller is optional, and the Microsoft HD Audio bus driver may or may not use the additional information, depending on the bus-interface type.

Plug and Play Requirements for HD Audio Bus Controllers:

• The HD Audio bus controller must follow Microsoft's guidelines with respect to the various Plug and Play device identifiers for the bus that connects the controller to the PC system (for example, the Plug and Play device-identification rules for the PCI or PCI Express bus).>

• HD Audio bus controllers that attach to PCI or PCI Express buses must expose the High Definition Audio PCI class and subclass ID value, 0x0403. The correct enumeration of an HD Audio controller by the Microsoft PCI enumerator depends on its use of this ID value. If the HD Audio controller does not expose the correct class and subclass ID, the system will not load the Microsoft HD Audio bus driver and subsequently no HD Audio function drivers will load on that machine.

• An HD Audio controller that attaches to a particular interface bus might be capable of providing additional Plug and Play device-identification information that is defined by the interface specification. Currently, the Microsoft HD Audio bus driver uses only the class and subclass ID and does not make use of this additional, interface-specific information (for example, the identity of the manufacturer of the HD Audio controller).

 Top of page

HD Audio Codecs

The term HD Audio codec refers to any device that attaches to the HD Audio Link and is controlled by an HD Audio controller.

During device enumeration, the Microsoft HD Audio bus driver queries an HD Audio codec for hardware identification information that it then provides to the Windows Plug and Play manager. In response to commands from the bus driver, an HD Audio codec must be prepared to supply the following information:

• 16-bit vendor ID

• 16-bit device ID

• 32-bit subsystem ID

• 16-bit extended revision ID

The bus driver requires the codec to provide all four IDs. In particular, the extended revision ID is not optional.

This section describes the usage of these four Plug and Play identifiers (vendor ID, device ID, subsystem ID, and extended revision ID) and presents guidelines that hardware and system vendors should follow in selecting values for these identifiers. Device, board, and system vendors should identify their codecs with sufficient precision to meet WHQL requirements and to enable proper driver-update functionality through Windows Update or other, third-party driver-distribution resources on the Web.

The 16-bit vendor ID and 16-bit device ID together identify the model of the HD Audio codec device (integrated circuit). The vendor ID identifies the vendor for the codec device. The codec vendor must obtain the vendor ID from the PCI Special Interest Group (PCI-SIG). The device ID distinguishes the codec model from other codec models made by the vendor. Both IDs are contained in the 32-bit Vendor ID response format (described in the Intel HD Audio specification), as shown in the following figure.

Figure 1. Vendor ID Response Format

If codec devices with the same vendor ID and device ID are used in several different board or system designs, the 32-bit subsystem ID helps to further identify the codec by distinguishing among the various system implementations of the supporting logic or codec SKU for the codec.

An HD Audio codec stores the subsystem ID in its 32-bit Subsystem ID register (described in the HD Audio specification), which is shown in the following figure.

Figure 2. Subsystem ID Register

In contrast to the 16-bit vendor ID and 16-bit device ID in Figure 1, which together identify an HD Audio codec device (integrated circuit), the 32-bit subsystem ID in Figure 2 identifies the board or system implementation that contains the codec device.

Board or systems vendors should use the entire 32-bit subsystem ID, which includes both the 24-bit board-implementation ID field and 8-bit assembly ID field, to identify the SKU of the board or system that contains the HD Audio codec. A vendor can use the fields in the subsystem ID to allow a custom HD Audio function driver to identify variations among codec board or system implementations with a high degree of precision.

If a board or system vendor provides custom drivers for several codec implementations, the subsystem ID can precisely determine which driver loads on each implementation. However, even vendors who do not supply custom drivers must follow the guidelines for valid subsystem IDs to prevent the loading of inappropriate drivers, which can result in system instability and bad user experiences. By providing valid subsystem IDs, vendors can ensure that their codecs will continue to meet "Designed for Windows" logo requirements in the future.

After booting up, the system BIOS loads the Subsystem ID register in the codec with a value that identifies the specific motherboard or system implementation that contains the codec. To make device identification more robust, the Subsystem ID register must power up with a default value in case the system BIOS fails for any reason to initialize the register. The register contents must not be undefined.

The default value, which is stored in the integrated circuitry of the codec device, loads automatically into the Subsystem ID register when the device powers up. The selection of an appropriate default value is left to the discretion of the codec device manufacturer, but the value must be nonzero and must not vary from one power-up to the next. The device manufacturer should devise an identification system that guarantees a unique default subsystem ID for each variation of a codec device that has the same device ID.

Note that providing a default subsystem ID that is unique for each codec device variation does not eliminate the need for a unique revision ID (see Figure 3). Typically, the system overwrites the default subsystem ID, following the guidelines in this document, and only the revision ID remains to distinguish among variations of the same codec device.

Through the system BIOS, the system can overwrite the codec vendor's default subsystem ID with a value that more precisely identifies the audio subsystem that the system designer has implemented. Note that several motherboard or system implementations might use the same codec model (identified by the vendor ID and device ID in Figure 1), and the value that the system BIOS writes to the 24-bit board-implementation ID field (overwriting this portion of the default subsystem ID) should distinguish the current motherboard or system implementation from the other implementations. In other words, after the BIOS has overwritten the Subsystem ID register, the combination of 16-bit vendor ID, 16-bit device ID, and 24-bit board-implementation ID should uniquely identify a particular motherboard or system implementation.

The 8-bit assembly ID is available to the codec, board, or system vendor for use in identifying any pin-strapping options or other board-specific identification information that might affect the selection or configuration of a function driver. For example, the assembly ID might identify the HD Audio codec implementation on a particular retail add-in card. Typically, the encoding of the assembly ID is based on a proprietary scheme devised by the vendor.

In the case of a codec on an add-in card, the BIOS typically does not overwrite the Subsystem ID register (or any other register) in the codec. Even if the BIOS can detect the presence of the add-in card, it might not recognize the card or be able to determine an appropriate value to write to the Subsystem ID register. For example, the codec device or card might have been designed after the BIOS was written. If the BIOS does not write to the Subsystem ID register, driver selection must be based on the default subsystem ID, and the assembly ID in bits 0-7 of the register is necessary to distinguish the add-in card model from other add-in card models that might incorporate the same codec device.

The codec vendor can choose to implement the 8-bit assembly ID field in the Subsystem ID register as read-only, in which case the system BIOS is able to overwrite only the register's 24-bit board-implementation ID field. Alternately, if the codec vendor chooses to make the entire Subsystem ID register writeable, including the assembly ID field, the default value for the assembly ID can be latched at power-up into bits 0-7 of the register at the same time that bits 8-31 of the register are loaded from a hardwired default value stored in the codec integrated circuitry, as described previously. Thereafter, the system BIOS can overwrite the entire contents of the register.

The 16-bit extended revision ID is included in the 32-bit Revision ID response format (described in the HD Audio specification), as shown in the following figure.

Figure 3. Revision ID Response Format

The extended revision ID in bits 8-23 consists of the following fields:

• An 8-bit revision ID that specifies a particular hardware revision of the codec that is identified by the 16-bit device ID in Figure 1.

• The 4-bit major and minor revision numbers that together specify the version of the HD Audio specification that the codec complies with.

The HD Audio bus driver currently ignores the stepping ID.

Plug and Play Requirements for HD Audio Codecs:

• An HD Audio codec device must supply a 16-bit vendor ID (see Figure 1) that uniquely identifies the codec vendor. The PCI Special Interest Group (PCI-SIG) assigns vendor IDs to vendors of PCI-based devices, boards, and system products. If the vendor for an HD Audio codec does not have a PCI-SIG-assigned vendor ID, then the vendor must apply for one through the PCI-SIG before shipping HD Audio products. Under no circumstances can an HD Audio codec vendor make use of a vendor ID that PCI-SIG has assigned to another company.

• An HD Audio codec must have a 16-bit device ID (see Figure 1) that is unique to the codec SKU. If the vendor adds or removes features from the codec, each hardware variation must be identified by a unique device ID. Unless two codecs share the same identical set of features, they must not share the same device ID.

• Each HD Audio codec hardware change that requires a corresponding software change in the function driver must be identified by a unique 8-bit revision ID (see Figure 3). In addition, if a hardware problem requires a software workaround, and a subsequent hardware change eliminates the need for the software workaround, that hardware change must be identified by a unique revision ID.

• An HD Audio codec must have a unique 32-bit subsystem ID (see Figure 2) that remains consistent across reboots and across all power-management state changes.

• The value that the system BIOS writes to the 32-bit Subsystem ID register (see Figure 2) identifies the system or environment in which the codec is implemented. The subsystem ID for a particular board or system implementation must distinguish that implementation from all other implementations with the same 16-bit vendor ID and 16-bit device ID (see Figure 1). In other words, the combination of vendor ID, device ID, and subsystem ID must uniquely identify the implementation. The subsystem ID is a combination of the following:

  • A 16-bit manufacturer ID

  • An 8-bit board SKU

  • An 8-bit assembly ID

  Note that the manufacturer ID is the vendor ID that PCI-SIG has assigned to the motherboard or system vendor. In contrast, the vendor ID in the Vendor ID response format (see Figure 1) identifies the vendor of the codec device (integrated circuit). The assembly ID specifies pin-strapping options or other board-specific wiring information, which can be provided in a proprietary format.

• The 16-bit extended revision ID (see Figure 3) helps to further differentiate codecs with the same 16-bit vendor ID, 16-bit device ID, and 32-bit subsystem ID. The extended revision ID consists of an 8-bit revision ID and 4-bit major and minor revision numbers, but does not include the stepping ID. Currently, the Microsoft UAA HD Audio framework does not use the stepping ID and does not expose the stepping ID to INF files for third-party, custom HD Audio function drivers.

 Top of page

INF Files for HD Audio Codecs

Vendors do not need to supply INF files for HD Audio codecs that rely entirely on the operating system for driver support. However, if vendors supply custom HD Audio function drivers, they must also provide INF files to install the drivers. To prevent a driver from being loaded for an inappropriate device or failing to load for an appropriate device, the INF file must precisely identify the HD Audio devices that the driver can and should control.

The device-identification strings that the INF file uses to identify a target HD Audio device for a custom driver should match one or more of the device-identification strings that the Microsoft HD Audio bus driver generates to identify the device. The bus driver generates a full-length device-identification string with the following format:

HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&SUBSYS_AAAAAAAA&REV_BBBB

The characters shown in italics in the preceding device ID represent hexadecimal digits. For example, "FUNC_01" is an example of a substring with the format "FUNC_XX".

The following table describes each substring in the device ID.

The Microsoft HD Audio bus driver generates hardware IDs with the following string formats:

HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&SUBSYS_AAAAAAAA&REV_BBBB



HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&SUBSYS_AAAAAAAA

The Microsoft HD Audio bus driver generates compatible IDs with the following string formats:

AUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&REV_BBBB



HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ



HDAUDIO\FUNC_XX&VEN_YYYY



HDAUDIO\FUNC_XX

Note that the last form of compatible ID in the preceding list (HDAUDIO\FUNC_XX) is similar to a class code, which denotes all audio function groups or all modem function groups. Third-party INF files must notuse the last two of the preceding string formats (HDAUDIO\FUNC_XX&VEN_YYYY and HDAUDIO\FUNC_XX).

A future version of the Plug and Play device-identification scheme for HD Audio devices might use an additional string element of the form ASY_CC, where CC is a string-formatted representation of the 8-bit assembly ID (see Figure 2).

The Plug and Play device-identification scheme for HD Audio devices is superior to the scheme defined in the AC'97 specification. First, the information for the HD Audio identification strings is read directly from the codec, which was not the case for the AC'97 identifiers. Second, through the information obtained from the widgets in the codec and the pin configuration default registers, the HD Audio specification supports an additional level of discoverability that is not available for AC'97 devices. These improvements will help to ensure that as the number of HD Audio devices and drivers increase in the future, the possibility of a driver loading on inappropriate hardware is virtually eliminated.

INF File Requirements for HD Audio Codec Devices:

• A third-party INF file for an HD Audio codec device must register a Plug and Play device-identification string containing a vendor ID and device ID (see Figure 1). The device-identification string for each supported codec device must be a unique combination of vendor ID and device ID. This string provides the same level of identification that is supported by legacy audio architectures such as AC'97. If necessary, the third-party INF can include additional, more specific Plug and Play identifiers either to enable the driver to load or to prevent it from loading on HD Audio codecs with the same vendor ID and device ID, but with different board or system identification information.

• The UAA guidelines allow third-party INF files for HD Audio codec devices to specify the Plug and Play device-identification strings in the following formats:

HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&SUBSYS_AAAAAAAA&REV_BBBB



HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&SUBSYS_AAAAAAAA



HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ&REV_BBBB



HDAUDIO\FUNC_XX&VEN_YYYY&DEV_ZZZZ

Third-party INF files for HD Audio codec devices must not specify Plug and Play device-identification strings in either of the following formats:

HDAUDIO\FUNC_XX&VEN_YYYY



HDAUDIO\FUNC_XX

 Top of page

References

Call to Action

• For system manufacturers:

  • Include UAA compliance in your product plans.

  • Encourage audio device vendors to build UAA-compliant devices.

• For audio device manufacturers:

  • Include UAA compliance in your product plans.

  • Contact Microsoft for information about designing UAA-compliant devices.

If you have questions about UAA, please send e-mail to uaa@microsoft.com.

UAA Compatibility Information

• For information about Windows compatibility guidelines for Intel HD Audio devices, send e-mail to Microsoft at uaa@microsoft.com.

• For information about Intel's High Definition Audio specification, send e-mail to Intel at nextgenaudio@intel.com.

• For an overview of Microsoft's UAA initiative, see Universal Audio Architecture.

PCI-SIG Vendors IDs

• Manufacturers of HD Audio devices can obtain vendor IDs from the PCI Special Interest Group at http://www.pcisig.com .

Intel High Definition Audio Disclaimer

The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Intel Corporation. Intel assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document.

CERTAIN INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice.

Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.

This document contains information on products in the design phase of development. Do not finalize a design with this information.

 Top of page