-->

Open the USB Audio Driver folder on your desktop. Right click on the setup application (setup.exe) and select ‘Properties’ to open the properties tab. Click on the ‘Compatibility’ tab and tick the selection box for ‘Run this program in compatibility mode for:’. Select ‘Windows 7’ from the drop down box and press the ‘OK’ button. What is USB PnP Sound Device Drivers. Basically, it is a sound card device that reads the audio signal from the bit form in the waveform. And, then transmits the data into the audio form to the headphones and the speakers that we can listen to. Similarly, the USB PnP sound device is an external sound card that you can Plug and Play via the USB.

This section describes the sequence of events that occur when the system configures a PnP device that a user has added to a running machine. This discussion highlights the roles of the PnP manager, bus drivers, and function and filter drivers in enumerating and configuring a new device.

Most of this discussion is also relevant to configuring a PnP device that is present when the machine is booted. Specifically, devices whose drivers are marked SERVICE_DEMAND_START in an INF file are configured in essentially the same way whether the device is added dynamically or is present at boot time.

The following figure shows the first steps in configuring the device, starting from when the user plugs the hardware into the machine.

The following notes correspond to the circled numbers in the previous figure:

1. A user plugs a PnP device into a free slot on a PnP bus.

   In this example, the user plugs a PnP USB joystick into the hub on a USB host controller. The USB hub is a PnP bus device because child devices can be attached to it.

2. The function driver for the bus device determines that a new device is on its bus.

   How the driver determines this depends on the bus architecture. For some buses, the bus function driver receives hot-plug notification of new devices. If the bus does not support hot-plug notification, the user must take appropriate action in Control Panel to cause the bus to be enumerated.

   In this example, the USB bus supports hot-plug notification so the function driver for the USB bus is notified that its children have changed.

3. The function driver for the bus device notifies the PnP manager that its set of child devices has changed.

   The function driver notifies the PnP manager by calling IoInvalidateDeviceRelations with a Type of BusRelations.

4. The PnP manager queries the bus's drivers for the current list of devices on the bus.

   The PnP manager sends an IRP_MN_QUERY_DEVICE_RELATIONS request to the device stack for the bus. The Parameters.QueryDeviceRelations.Type value is BusRelations, indicating that the PnP manager is asking for the current list of devices present on the bus (bus relations).

   The PnP manager sends the IRP to the top driver in the device stack for the bus. According to the rules for PnP IRPs, each driver in the stack handles the IRP, if appropriate, and passes the IRP down to the next driver.

5. The function driver for the bus device handles the IRP.

   See the reference page for IRP_MN_QUERY_DEVICE_RELATIONS for detailed information about handling this IRP.

   In this example, the USB hub driver handles this IRP for the hub FDO. The hub driver creates a PDO for the joystick device and includes a referenced pointer to the joystick PDO in its list of child devices returned with the IRP.

   When the USB hub's parent bus driver (the USB host controller class/miniclass driver pair) completes the IRP, the IRP travels back up the device stack by means of any IoCompletion routines registered by the hub drivers.

Note that the bus function driver reports a change in its list of children by requesting that the PnP manager query for its list of child devices. The resulting IRP_MN_QUERY_DEVICE_RELATIONS request is seen by all the drivers for the bus device. Typically, the bus function driver is the only driver to handle the IRP and report children. In some device stacks, a bus filter driver is present and participates in constructing the list of bus relations. One example is ACPI, which attaches as a bus filter driver for ACPI devices. In some device stacks, nonbus filter drivers handle the IRP_MN_QUERY_DEVICE_RELATIONS request, but this is not typical.

At this point, the PnP manager has the current list of devices on the bus. The PnP manager then determines whether any devices are newly arrived or have been removed. In this example, there is one new device. The following figure shows the PnP manager creating a devnode for the new device and beginning to configure the device.

The following notes correspond to the circled numbers in the previous figure:

1. The PnP manager creates devnodes for any new child devices on the bus.

   The PnP manager compares the list of bus relations returned in the IRP_MN_QUERY_DEVICE_RELATIONS IRP to the list of children for the bus currently recorded in the PnP device tree. The PnP manager creates a devnode for each new device and initiates removal processing for any devices that have been removed.

   In this example, there is one new device (a joystick), so the PnP manager creates a devnode for the joystick. At this point, the only driver that is configured for the joystick is the parent USB hub bus driver, which created the joystick's PDO. Any optional bus filter drivers would also be present in the device stack, but the example omits bus filter drivers for simplicity.

   The wide arrow between the two devnodes in the previous figure indicates that the joystick devnode is a child of the USB hub devnode.

2. The PnP manager gathers information about the new device and begins configuring the device.

   The PnP manager sends a sequence of IRPs to the device stack to gather information about the device. At this point, the device stack consists of only the PDO created by the device's parent bus driver and filter DOs for any optional bus filter drivers. Therefore, the bus driver and bus filter drivers are the only drivers that respond to these IRPs. In this example, the only driver in the joystick device stack is the parent bus driver, the USB hub driver.

   The PnP manager gathers information about a new device by sending IRPs to the device stack. These IRPs include the following:

   • IRP_MN_QUERY_ID, a separate IRP for each of the following types of hardware IDs:

     BusQueryDeviceID

     BusQueryInstanceID

     BusQueryHardwareIDs

     BusQueryCompatibleIDs

     BusQueryContainerID

   • IRP_MN_QUERY_DEVICE_TEXT, a separate IRP for each of the following items:

     DeviceTextDescription

     DeviceTextLocationInformation

   The PnP manager sends the IRPs listed above at this stage of processing a new PnP device, but not necessarily in the order listed, so you should not make assumptions about the order in which the IRPs are sent. Also, you should not assume that the PnP manager sends only the IRPs listed above.

   The PnP manager checks the registry to determine whether the device has been installed on this machine previously. The PnP manager checks for an <enumerator><deviceID> subkey for the device under the Enum branch. In this example, the device is new and must be configured 'from scratch.'

3. The PnP manager stores information about the device in the registry.

   The registry's Enum branch is reserved for use by operating system components and its layout is subject to change. Driver writers must use system routines to extract information related to drivers. Do not access the Enum branch directly from a driver. The following Enum information is listed for debugging purposes only.

   • The PnP manager creates a subkey for the device under the key for the device's enumerator.

     The PnP manager creates a subkey named HKLMSystemCurrentControlSetEnum<enumerator><deviceID>. It creates the <enumerator> subkey if it does not already exist.

     An enumerator is a component that discovers PnP devices based on a PnP hardware standard. The tasks of an enumerator are carried out by a PnP bus driver in partnership with the PnP manager. A device is typically enumerated by its parent bus driver, such as PCI or PCMCIA. Some devices are enumerated by a bus filter driver, such as ACPI.

   • The PnP manager creates a subkey for this instance of the device.

     If Capabilities.UniqueID is returned as TRUE for IRP_MN_QUERY_CAPABILITIES, the device's unique ID is unique across the system. If not, the PnP manager modifies the ID so that it is unique system-wide.

     The PnP manager creates a subkey named HKLMSystemCurrentControlSetEnum<enumerator><deviceID><instanceID>.

   • The PnP manager writes information about the device to the subkey for the device instance.

     The PnP manager stores information, including the following, if it was supplied for the device:

     DeviceDesc — from IRP_MN_QUERY_DEVICE_TEXT

     Location — from IRP_MN_QUERY_DEVICE_TEXT

     Capabilities — the flags from IRP_MN_QUERY_CAPABILITIES

     UINumber — from IRP_MN_QUERY_CAPABILITIES

     HardwareID — from IRP_MN_QUERY_ID

     CompatibleIDs — from IRP_MN_QUERY_ID

     ContainerID — from IRP_MN_QUERY_ID

     LogConfBootConfig — from IRP_MN_QUERY_RESOURCES

     LogConfBasicConfigVector — from IRP_MN_QUERY_RESOURCE_REQUIREMENTS

At this point, the PnP manager is ready to locate the function driver and filter drivers for the device, if any. (See the following figure.)

The following notes correspond to the numbered circles in the previous figure:

1. The kernel-mode PnP manager coordinates with the user-mode PnP manager and user-mode Setup components to find the function and filter drivers for the device, if there are any.

   The kernel-mode PnP manager queues an event to the user-mode PnP manager, identifying a device that needs to be installed. Once a privileged user logs in, the user-mode components proceed with finding drivers. See the device installation overview For information about Setup components and their role in installing a device.

2. The user-mode Setup components direct the kernel-mode PnP manager to load the function and filter drivers.

   The user-mode components call back to kernel mode to get the drivers loaded, causing their AddDevice routines to be called.

The following figure shows the PnP manager loading the drivers (if appropriate), calling their AddDevice routines, and directing the drivers to start the device.

The following notes correspond to the numbered circles in the previous figure:

1. Lower-filter drivers

   Before the function driver attaches to the device stack, the PnP manager processes any lower-filter drivers. For each lower-filter driver, the PnP manager calls the driver's DriverEntry routine if the driver is not yet loaded. Then the PnP manager calls the driver's AddDevice routine. In its AddDevice routine, the filter driver creates a filter device object (filter DO) and attaches it to the device stack (IoAttachDeviceToDeviceStack). Once it attaches its device object to the device stack, the driver is engaged as a driver for the device.

   In the USB joystick example, there is one lower-filter driver for the device.

2. Function driver

   After any lower filters are attached, the PnP manager processes the function driver. The PnP manager calls the function driver's DriverEntry routine if the driver is not yet loaded and calls the function driver's AddDevice routine. The function driver creates a function device object (FDO) and attaches it to the device stack.

   In this example, the function driver for the USB joystick is actually a pair of drivers: the HID class driver and the HID miniclass driver. The two drivers work together to serve as the function driver. The driver pair creates only one FDO and attaches it to the device stack.

3. Upper-filter drivers

   After the function driver is attached, the PnP manager processes any upper-filter drivers.

   In this example, there is one upper-filter driver for the device.

4. Assigning resources and starting the device

   The PnP manager assigns resources to the device, if needed, and issues an IRP to start the device.

   • Assigning resources

     Earlier in the configuration process, the PnP manager gathered the hardware resource requirements for the device from the device's parent bus driver. After the full set of drivers is loaded for the device, the PnP manager sends an IRP_MN_FILTER_RESOURCE_REQUIREMENTS request to the device stack. All drivers in the stack have the opportunity to handle this IRP and modify the device's resource requirements list, if necessary.

     The PnP manager assigns resources to the device, if the device requires any, based on the device's requirements and the resources currently available.

     The PnP manager might need to rearrange the resource assignments of existing devices to satisfy the needs of the new device. This reassignment of resources is called 'rebalancing.' The drivers for the existing devices receive a sequence of stop and start IRPs during a rebalance, but the rebalance must be transparent to users.

     In the example of the USB joystick, USB devices do not require hardware resources so the PnP manager sets the resource list to NULL.

   • Starting the device (IRP_MN_START_DEVICE)

     Once the PnP manager assigns resources to the device, it sends an IRP_MN_START_DEVICE IRP to the device stack to direct the drivers to start the device.

   After the device is started, the PnP manager sends three more IRPs to the drivers for the device:

   • After the start IRP completes successfully, the PnP manager sends another IRP_MN_QUERY_CAPABILITIES IRP to the device stack. All the drivers for the device have the option of handling the IRP. The PnP manager sends this IRP at this time, after all drivers are attached and the device is started, because the function or filter drivers might need to access the device to collect capability information.

   • This IRP gives a driver the opportunity to, for example, report that the device should not be displayed in user interfaces such as Device Manager and the Hotplug program. This is useful for devices that are present on a system but are not usable in the current configuration, such as a game port on a laptop that is not usable when the laptop is undocked.

   • IRP_MN_QUERY_DEVICE_RELATIONS for bus relations

     The PnP manager sends this IRP to determine whether the device has any child devices. If so, the PnP manager configures each child device.

Using GUID_PNP_LOCATION_INTERFACE

The GUID_PNP_LOCATION_INTERFACE interface supplies the SPDRP_LOCATION_PATHS Plug and Play (PnP) device property for a device.

To implement this interface in your driver, handle the IRP_MN_QUERY_INTERFACE IRP with InterfaceType = GUID_PNP_LOCATION_INTERFACE. Your driver supplies a pointer to a PNP_LOCATION_INTERFACE structure that contains pointers to the individual routines of the interface. The PnpGetLocationString routine provides the device-specific part of the device's SPDRP_LOCATION_PATHS property.

Starting with Windows 10, release 1703, a USB Audio 2.0 driver is shipped with Windows. It is designed to support the USB Audio 2.0 device class. The driver is a WaveRT audio port class miniport. For more information about the USB Audio 2.0 device class, see https://www.usb.org/documents?search=&type%5B0%5D=55&items_per_page=50.

The driver is named: usbaudio2.sys and the associated inf file is usbaudio2.inf.

The driver will identify in device manager as 'USB Audio Class 2 Device'. This name will be overwritten with a USB Product string, if it is available.

The driver is automatically enabled when a compatible device is attached to the system. However, if a third-party driver exists on the system or Windows Update, that driver will be installed and override the class driver.

Architecture

usbaudio2.sys fits within the wider architecture of Windows USB Audio as shown.

Related USB specifications

The following USB specifications define USB Audio and are referenced in this topic.

• USB-2 refers to the Universal Serial Bus Specification, Revision 2.0
• ADC-2 refers to the USB Device Class Definition for Audio Devices, Release 2.0.
• FMT-2 refers to the Audio Data Formats specification, Release 2.0.

The USB-IF is a special interest group that maintains the Official USB Specification, test specifications and tools.

Audio formats

The driver supports the formats listed below. An alternate setting which specifies another format defined in FMT-2, or an unknown format, will be ignored.

Type I formats (FMT-2 2.3.1):

• PCM Format with 8..32 bits per sample (FMT-2 2.3.1.7.1)
• PCM8 Format (FMT-2 2.3.1.7.2)
• IEEE_FLOAT Format (FMT-2 2.3.1.7.3)

Type III formats (FMT-2 2.3.3 and A.2.3):

• IEC61937_AC-3
• IEC61937_MPEG-2_AAC_ADTS
• IEC61937_DTS-I
• IEC61937_DTS-II
• IEC61937_DTS-III
• TYPE_III_WMA

Feature descriptions

This section describes the features of the USB Audio 2.0 driver.

Audio function topology

The driver supports all entity types defined in ADC-2 3.13.

Each Terminal Entity must have a valid clock connection in compatible USB Audio 2.0 hardware. The clock path may optionally include Clock Multiplier and Clock Selector units and must end in a Clock Source Entity.

The driver supports one single clock source only. If a device implements multiple clock source entities and a clock selector, then the driver will use the clock source that is selected by default and will not modify the clock selector’s position.

A Processing Unit (ADC-2 3.13.9) with more than one input pin is not supported.

An Extension Unit (ADC-2 3.13.10) with more than one input pin is not supported.

Cyclic paths in the topology are not allowed.

Audio streaming

The driver supports the following endpoint synchronization types (USB-2 5.12.4.1):

• Asynchronous IN and OUT
• Synchronous IN and OUT
• Adaptive IN and OUT

For the asynchronous OUT case the driver supports explicit feedback only. A feedback endpoint must be implemented in the respective alternate setting of the AS interface. The driver does not support implicit feedback.

There is currently limited support for devices using a shared clock for multiple endpoints.

For the Adaptive IN case the driver does not support a feedforward endpoint. If such an endpoint is present in the alternate setting, it will be ignored. The driver handles the Adaptive IN stream in the same way as an Asynchronous IN stream.

The size of isochronous packets created by the device must be within the limits specified in FMT-2.0 section 2.3.1.1. This means that the deviation of actual packet size from nominal size must not exceed +/- one audio slot (audio slot = channel count samples).

Descriptors

An audio function must implement exactly one AudioControl Interface Descriptor (ADC-2 4.7) and one or more AudioStreaming Interface Descriptors (ADC-2 4.9). A function with an audio control interface but no streaming interface is not supported.

The driver supports all descriptor types defined in ADC-2, section 4. The following subsections provide comments on some specific descriptor types.

Class-Specific AS interface descriptor

For details on this specification, refer to ADC-2 4.9.2.

An AS interface descriptor must start with alternate setting zero with no endpoint (no bandwidth consumption) and further alternate settings must be specified in ascending order in compatible USB Audio 2.0 hardware.

An alternate setting with a format that is not supported by the driver will be ignored.

Each non-zero alternate setting must specify an isochronous data endpoint, and optionally a feedback endpoint. A non-zero alternate setting without any endpoint is not supported.

The bTerminalLink field must refer to a Terminal Entity in the topology and its value must be identical in all alternate settings of an AS interface.

The bFormatType field in the AS interface descriptor must be identical to bFormatType specified in the Format Type Descriptor (FMT-2 2.3.1.6).

For Type I formats, exactly one bit must be set to one in the bmFormats field of the AS interface descriptor. Otherwise, the format will be ignored by the driver.

To save bus bandwidth, one AS interface can implement multiple alternate settings with the same format (in terms of bNrChannels and AS Format Type Descriptor) but different wMaxPacketSize values in the isochronous data endpoint descriptor. For a given sample rate, the driver selects the alternate setting with the smallest wMaxPacketSize that can fulfill the data rate requirements.

Type I format type descriptor

For details on this specification, refer to FMT-2 2.3.1.6.

The following restrictions apply:

Class-Specific AS isochronous audio data endpoint descriptor

For details on this specification, refer to ADC-2 4.10.1.2.

The MaxPacketsOnly flag in the bmAttributes field is not supported and will be ignored.

The fields bmControls, bLockDelayUnits and wLockDelay will be ignored.

Class requests and interrupt data messages

The driver supports a subset of the control requests defined in ADC-2, section 5.2, and supports interrupt data messages (ADC-2 6.1) for some controls. The following table shows the subset that is implemented in the driver.

Additional information on the controls and requests is available in the following subsections.

Clock source entity

For details on this specification, refer to ADC-2 5.2.5.1.

At a minimum, a Clock Source Entity must implement Sampling Frequency Control GET RANGE and GET CUR requests (ADC-2 5.2.5.1.1) in compatible USB Audio 2.0 hardware.

The Sampling Frequency Control GET RANGE request returns a list of subranges (ADC-2 5.2.1). Each subrange describes a discrete frequency, or a frequency range. A discrete sampling frequency must be expressed by setting MIN and MAX fields to the respective frequency and RES to zero. Individual subranges must not overlap. If a subrange overlaps a previous one, it will be ignored by the driver.

A Clock Source Entity which implements one single fixed frequency only does not need to implement Sampling Frequency Control SET CUR. It implements GET CUR which returns the fixed frequency, and it implements GET RANGE which reports one single discrete frequency.

Clock selector entity

For details on this specification, refer to ADC-2 5.2.5.2

The USB Audio 2.0 driver does not support clock selection. The driver uses the Clock Source Entity which is selected by default and never issues a Clock Selector Control SET CUR request. The Clock Selector Control GET CUR request (ADC-2 5.2.5.2.1) must be implemented in compatible USB Audio 2.0 hardware.

Feature unit

For details on this specification, refer to ADC-2 5.2.5.7.

The driver supports one single volume range only. If the Volume Control GET RANGE request returns more than one range, then subsequent ranges will be ignored.

The volume interval expressed by the MIN and MAX fields should be an integer multiple of the step size specified in the RES field.

If a feature unit implements single channel controls as well as a master control for Mute or Volume, then the driver uses the single channel controls and ignores the master control.

Additional Information for OEM and IHVs

OEMs and IHVs should test their existing and new devices against the supplied in-box driver.

Usb Pnp Audio Device Driver Error

There is not any specific partner customization that is associated with the in-box USB Audio 2.0 driver.

This INF file entry (provided in a update to Windows Release 1703), is used to identify that the in-box driver is a generic device driver.

The in-box driver registers for the following compatible IDs with usbaudio2.inf.

See the USB audio 2.0 specification for subclass types.

USB Audio 2.0 Devices with MIDI (subclass 0x03 above) will enumerate the MIDI function as a separate multi-function device with usbaudio.sys (USB Audio 1.0 driver) loaded.

Usb Pnp Audio Device Drivers Download

The USB Audio 1.0 class driver registers this compatible ID with wdma_usb.inf.

And has these exclusions:

An arbitrary number of channels (greater than eight) are not supported in shared mode due to a limitation of the Windows audio stack.

IHV USB Audio 2.0 drivers and updates

For IHV provided third party driver USB Audio 2.0 drivers, those drivers will continue to be preferred for their devices over our in-box driver unless they update their driver to explicitly override this behavior and use the in-box driver.

Audio Jack Registry Descriptions

Starting in Windows 10 release 1703, IHVs that create USB Audio Class 2.0 devices having one or more jacks have the capability to describe these jacks to the in-box Audio Class 2.0 driver. The in-box driver uses the supplied jack information when handling the KSPROPERTY_JACK_DESCRIPTION for this device.

Jack information is stored in the registry in the device instance key (HW key).

The following describes the audio jack information settings in the registry:

<tid> = terminal ID (As defined in the descriptor)

<n> = Jack number (1 ~ n).

Convention for <tid> and <n> is:

• Base 10 (8, 9, 10 rather than 8, 9, a)
• No leading zeros
• n is 1-based (first jack is jack 1 rather than jack 0)

For example:

T1_NrJacks, T1_J2_ChannelMapping, T1_J2_ConnectorType

For additional audio jack information, see KSJACK_DESCRIPTION structure.

These registry values can be set in various ways:

• By using custom INFs which wrap the in-box INF for the purpose to set these values.

• Directly by the h/w device via a Microsoft OS Descriptors for USB devices (see example below). For more information about creating these descriptors, see Microsoft OS Descriptors for USB Devices.

Microsoft OS Descriptors for USB Example

The following Microsoft OS Descriptors for USB example contains the channel mapping and color for one jack. The example is for a non-composite device with single feature descriptor.

The IHV vendor should extend it to contain any other information for the jack description.

Troubleshooting

If the driver does not start, the system event log should be checked. The driver logs events which indicate the reason for the failure. Similarly, audio logs can be manually collected following the steps described in this blog entry. If the failure may indicate a driver problem, please report it using the Feedback Hub described below, and include the logs.

For information on how to read logs for the USB Audio 2.0 class driver using supplemental TMF files, see this blog entry. For general information on working with TMF files, see Displaying a Trace Log with a TMF File.

For information on 'Audio services not responding' error and USB audio device does not work in Windows 10 version 1703 see, USB Audio Not Playing

Feedback Hub

If you run into a problem with this driver, collect audio logs and then follow steps outlined in this blog entry to bring it to our attention via the Feedback Hub.

Driver development

This USB Audio 2.0 class driver was developed by Thesycon and is supported by Microsoft.

See also