Audio Endpoint Driver Windows 10


Audio driver windows 10 free download - Windows 10, Apple Safari, Realtek High Definition Audio Codec (Windows 7 / 8/ 8.1/ 10 64-bit), and many more programs. The Best Free Audio Drivers app downloads for Windows: Realtek High Definition Audio Codec (Windows 7 / 8/ 8.1/ 10 64-bit) Realtek High Definition Aud.


In Windows Vista, Windows Server 2008 and later versions of Windows, the audio subsystem supports the notion of an audio endpoint device, for example, speakers, headphones, microphones, and CD players. This concept of audio endpoints helps create user-friendly audio applications that have user interfaces that refer to the endpoint devices that users directly manipulate. These endpoints have friendly names such as 'speakers', 'headphones', 'microphone', and 'CD player' that applications can display in their user interfaces. For more information about endpoint devices, see Audio Endpoint Devices.

The audio subsystem models a Plug and Play (PnP) device on an audio adapter as a KS filter. Data streams enter and exit the filter through KS pins. A bridge pin is a KS pin through which an audio endpoint device connects to a KS filter. For more information about bridge pins, see Audio Filter Graphs.

The audio subsystem obtains information about an audio endpoint device by examining the properties of the bridge pin that the endpoint device connects to. One such property is the pin category property (KSPROPERTY_PIN_CATEGORY).

For each KS filter, the adapter driver supplies a table of PCPIN_DESCRIPTOR structures that describe the properties of the KS pins on the filter. The pin category GUID is stored in the KsPinDescriptor.Category member of the PCPIN_DESCRIPTOR structure. For a bridge pin, the value of the pin category GUID indicates the type of endpoint that connects to the bridge pin. For example, the pin-category GUID KSNODETYPE_MICROPHONE indicates that the bridge pin connects to a microphone, the GUID KSNODETYPE_SPEAKER indicates that the bridge pin connects to speakers, and so on. The KSNODETYPE_XXX GUIDs are defined in the Ksmedia.h header file.

In addition the PCPIN_DESCRIPTOR includes a GUID that can be used to identify the pin by a unique name. This pin name GUID is stored in the KsPinDescriptor.Name member of the PCPIN_DESCRIPTOR structure. This name GUID is used by the (KSPROPERTY_PIN_NAME) property to associate a friendly name found in the registry with the pin.

The audio subsystem invokes the KSPROPERTY_PIN_NAME property to associate a friendly name with an audio endpoint. KS handles this request by first searching for a unicode string in the registry describing the KsPinDescriptor.Name GUID. If KS does not find an entry, it searches the registry for a unicode string describing the KsPinDescriptor.Category GUID.

Starting with Windows 10 REDSTONE 5 when searching the registry, KS first looks for an entry in the device's software key. This is created by the INF through an AddReg section referenced by the [Models] section of the device driver's INF. The AddReg section constructs these entries using the HKRMediaCategories key. This allows the driver developer to create device-specific friendly names for both Name and Category GUIDs, whether the GUID is unique to the device or not.

If an entry has not been installed in the device's software key or the driver is running on an operating system prior to Windows 10 REDSTONE 5, KS looks under HKLMSYSTEMCurrentControlSetControlMediaCategories registry key. This second key is treated as a global name space. Starting with Windows 10 REDSTONE 5 this space is reserved for global definitions and should not be modified by new drivers. Modification of entries under this key will not be supported in a future OS release.

Audio devices that expose pins with standard categories GUIDs should include / needs the inbox KS.INF or KSCAPTUR.INF name registration in your device INF. These inbox INFs contain default friendly name definitions for pre-defined category GUIDs that your driver may wish to populate. These are the same GUIDs found in the KsPinDescriptor.Category member of the PCPIN_DESCRIPTOR structure. For example, the category GUID KSNODETYPE_MICROPHONE entry has the associated friendly name 'microphone' and the category GUID KSNODETYPE_SPEAKER entry has the associated friendly name 'speakers,' and so on.

The GUIDs and friendly names for both Category and Name GUIDs are stored under the HKRMediaCategories while global definitions HKLMSYSTEMCurrentControlSetControlMediaCategories paths. For each GUID-name pair in the registry, the GUID string is used as a sub-key under the MediaCategories key. Under the GUID key the friendly name a Unicode string value under the 'Name' variable.

If none of the friendly names and pin categories defined by the audio subsystem adequately describes your device, you can define your own pin category and name GUIDs and associate friendly names with them in your INF. To ensure that your pin-category GUID is unique, use a utility such as Uuidgen.exe to generate the GUID. Next, modify the INF file that installs your audio adapter to write the pin-category GUID and friendly name to the registry path HKRMediaCategories. The following code example shows a fragment of an INF file that adds two pin-category GUIDs and their associated friendly names to the registry:

Both GUID strings were generated by Uuidgen.exe.

Applications can access the properties of an audio endpoint device by using the device's IPropertyStore interface. The interface uses the property keys defined in the Functiondiscoverykeys_devpkey.h and Mmdeviceapi.h header files to identify the properties. An application can use the PKEY_Device_FriendlyName property key to retrieve the friendly name of an endpoint device. For space-constrained user interfaces, a shorter version of the friendly name can be retrieved by using the PKEY_Device_DeviceDesc property key. For more information about these property keys, see IMMDevice::OpenPropertyStore.

An IPropertyStore interface instance maintains a persistent property store for an audio endpoint device. The property store copies its initial value for the PKEY_Device_DeviceDesc property key from the friendly name string that is associated with the KS pin category GUID in the registry path HKLMSYSTEMCurrentControlSetControlMediaCategories. Applications can read the PKEY_Device_DeviceDesc property value (the name string) from the property store, but they cannot change the value. However, users can modify the name by using the Windows multimedia control panel, Mmsys.cpl. For example, in Windows Vista, you can use the following steps to modify the name of a rendering endpoint device:

  1. To run Mmsys.cpl, open a Command Prompt window and enter the following command:

    (Alternatively, you can run Mmsys.cpl by right-clicking the speaker icon in the notification area, which is located on the right side of the taskbar, and clicking Playback Devices.)

  2. Click the name of a rendering device, and then click Properties.

  3. In the Properties window, click the General tab. The friendly name should appear in a text box at the top of the property sheet. You can edit the friendly name, and then save your changes by clicking OK.

The preceding steps change the friendly name that is stored in the property store for the audio endpoint device. These steps have no effect on the friendly names associated with other audio endpoint devices that belong to the same KS pin category. They also have no effect on any component that might query KS directly for a name.


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

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.


USBAudio.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 (FMT20
  • PCM8 Format (FMT-2
  • IEEE_FLOAT Format (FMT-2

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

Feature descriptions

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

Audio function topology

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

Game crack for mac. 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

  • 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 This means that the deviation of actual packet size from nominal size must not exceed +/- one audio slot (audio slot = channel count samples).


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 ADC20, 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

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

The following restrictions apply:

FormatSubslot sizeBit resolution
Type I PCM format:1 <= bSubslotSize <= 48 <= bBitResolution <= 32
Type I PCM8 format:bSubslotSize 1bBitResolution 8
Type I IEEE_FLOAT format:bSubslotSize 4bBitResolution 32
Type III IEC61937 formats:bSubslotSize 2bBitResolution 16

Class-Specific AS isochronous audio data endpoint descriptor

Audio Endpoint Driver Windows 10

For details on this specification, refer to ADC-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.

Clock SourceSampling Frequency Controlxxx
Clock SelectorClock Selector Controlx
Clock MultiplierNumerator Controlx
Denominator Controlx
TerminalConnector Controlxx
Mixer UnitMixer Controlxxx
Selector UnitSelector Controlxx
Feature UnitMute Controlxxx
Volume Controlxxxx
Automatic Gain Controlxx
Effect Unit
Processing Unit
Extension Unit

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


At a minimum, a Clock Source Entity must implement Sampling Frequency Control GET RANGE and GET CUR requests (ADC-2 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

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 must be implemented in compatible USB Audio 2.0 hardware.

Feature unit

For details on this specification, refer to ADC-2

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. Samsung tv remote app for mac.

Additional Information for OEM and IHVs

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

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.

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:

Audio Endpoint Driver Windows 10

  • 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:

Audio Endpoint Driver For Windows 10

  • 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.


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

Comments are closed.