Osblog623

• Amazon.com: usb audio mac. Skip to main content. Try Prime EN Hello, Sign in Account & Lists Sign in Account & Lists Returns & Orders Try Prime Cart.
• USB-MIDI Driver V1.3.2-2 for Mac macOS 10.15-OS X 10.5. The USB-MIDI Driver is for use with Studio Manager V2 Host and Editor. Be sure to use the latest versions of both the Studio Manager V2 Host and Editor available on this Yamaha Pro Audio site. Main Revisions and Enhancements.

Mac: The driver should show up twice, as a HAL-plugin (not on Mac OS X 10.15!) and a CoreAudio driver in AUDIO/MIDI setup. If you're using Digidesign's Mbox disable the Digidesign USB extension in order to use the USB Audio driver. USB Audio 2.0 Drivers.; 11 minutes to read; In this article. 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. FREE SHIPPING ON ALL ORDERS OVER $30 Fast Charger Fast Charger. PD Charger; Car Charger; Power Bank; Wireless Charger.

To successfully design a class compliant USB audio device that works seamlessly with the Mac, it is important to understand the features of the Mac's USB audio class driver, AppleUSBAudio. This document explains the driver's architecture, features, and algorithms available in Mac OS X v10.6 and later. It also includes a section discussing recently enhanced support for devices that comply with the USB Device Class Definition for Audio Devices 2.0 specification. The insights and design tips presented here are intended to assist device developers in creating high quality plug-and-play USB audio devices.

Background

This document assumes the reader is familiar with the Core Audio framework, Audio HAL, I/O Kit basics and USB fundamentals. Please review these documents for more information:

Note: There is often confusion when referencing the various USB related specifications. See Table 1 for a summary of the terms used in this article to reference USB specifications.

The reader is strongly encouraged to review the documents in Table 1.

Class Driver Overview

AppleUSBAudio is an I/O Kit based kernel driver that is designed to support both USB Audio 1.0 and USB Audio 2.0 class compliant devices. Figure 1 shows where AppleUSBAudio fits in the Mac OS X audio stack architecture. In addition to transporting audio data between the hardware and the host’s sample buffer, it also communicates format and control changes between the host and the device (like volume, mute, format, input/clock source, etc.) AppleUSBAudio presents these hardware resources to applications through the HAL (audio hardware abstraction layer.)

The AppleUSBAudio driver communicates to devices via the USB transport, using the IOUSBFamily APIs. AppleUSBAudio builds upon the IOAudioFamily layer which provides general audio driver functions like maintaining the sample and mix buffers, facilitating communication over the kernel and user space boundary through user clients, and more. Please see the Audio Device Driver Programming Guide for more details.

AppleUSBAudio is a mature driver that supports many USB Audio 1.0 and 2.0 features. Table 2 highlights some of the supported features that are discussed in this article.

Unified Engine Model

AppleUSBAudio represents the streams of a USB audio device to the application layer using IOAudioFamily's IOAudioStream entities. One or more streams are associated with each engine.

In Mac OS v10.5.6 and earlier, AppleUSBAudio restricted each engine to one stream only. Then in v10.5.7, AppleUSBAudio’s engine model was redesigned to combine multiple streams per engine when possible. In cases where input and output streams can reside on the same engine, this architecture achieves sample synchronization and consistent latencies between streams.

In order to combine multiple streams on one engine, the following criteria must be met by the stream interfaces:

1. All sample rate sets must match.

2. The same synchronization type is used for all interface alternate settings.

3. The streams reside in the same clock domain.

Please note the following behaviors of streams that occupy the same engine:

• These streams operate in the same time domain and sample rate setting (but not necessarily the same format.)

• These streams cannot be activated independently. They will always start and stop together.

Important: If a device is designed to combine multiple streams on a single engine, it must support starting multiple streams at the same time. If the device needs more time to do this, consider increasing the lock delay (see Section 4.6.1.2 of the USB Audio 1.0 Spec and Section 4.10.1.2 of the USB Audio 2.0 Spec.)

Artifact-free Streaming

The primary and most important function of the AppleUSBAudio driver is to support reliable, artifact-free audio streaming. Developers can aid the driver in achieving this goal by selecting the appropriate endpoint descriptor values for synchronization type and maximum packet size.

Endpoint Synchronization Types

To maintain glitch-free audio, AppleUSBAudio must regularly present timestamps to Core Audio that accurately represent the audio data rate of the engine (see “The Audio I/O Model Up Close” in the Audio Device Driver Programming Guide for more details.) When the device publishes the correct endpoint synchronization types in its configuration descriptors, AppleUSBAudio can pick the appropriate stream from which to generate the most accurate timestamps for the engine.

The driver supports all three synchronization types defined by the USB 2.0 Specification (see Section 5.12.4.1 Synchronization Type and Table 5-12):

• Synchronous: synced to host via SOF

• Asynchronous: not synced to host, data rate is locked to a free-running internal clock on the device or an external source like S/PDIF

• Adaptive: synced to host via data rate

Table 3 below lists synchronization type combinations that work well with Mac OS X.

If a device supports multiple clock domains, USB Audio 2.0 clock entity descriptors should be used to clearly communicate its clock architecture to AppleUSBAudio. Please see the Clock Entities section later in this article for information about these descriptors.

Note: Devices may use USB Audio 2.0 descriptors for full speed devices, not just high speed devices. This can be useful to more accurately describe full speed devices with complicated clock architectures such as multiple clock domains.

Feedback for Asynchronous Output Streams

To stream audio via an asynchronous sink endpoint, a device must continuously update the host of its desired data rate relative to the SOF frequency (see Section 5.10.4 of the USB 1.0 Spec and Section 5.12.4 of the USB 2.0 Spec.) AppleUSBAudio supports two feedback mechanisms:

1. Explicit feedback endpoint: The device provides an associated isochronous feedback endpoint which sends packets containing the number of samples per USB (micro)frame (see Section 3.7.2.2 of the USB Audio 1.0 Spec and Section 3.16.2.2 of the USB Audio 2.0 Spec.)

2. Implicit feedback: The driver uses the number of sample frames in the main input stream's packets to construct the packets for all output streams within the engine. No feedback endpoint is required (see Section 5.12.4.3 of the USB 2.0 Spec.)

In order to use implicit feedback, the device must satisfy the following requirements:

• Asynchronous input and output streams reside on one engine (i.e. needs to meet criteria for the Unified Engine Model.)

• The polling intervals (bInterval) for the stream endpoints must match.

• Either the input stream endpoint “Usage type” is set to “Implicit feedback data endpoint” (USB Audio 2.0 only, Section 4.10.1.1) and/or the sync feedback endpoint is omitted (see Table 4.)

Table 4 illustrates the synchronization method used by the driver in various scenarios. If indicated by the “Usage type” field, the driver will treat the input stream as implicit feedback and ignore an additional sync feedback endpoint if present (Config 2.) This allows a device to implement both feedback mechanisms if needed for compatibility reasons. Config 3 is only recommended for USB Audio 1.0 devices where endpoint “Usage type” is not available.

Note: We recommend using implicit feedback when possible because it conserves both device and host resources, and increases feedback precision.

Maximum Packet Size

It is very important to specify the correct value for each endpoint’s maximum packet size because an incorrect value could result in audio corruption. The packet size cannot exceed 1023 bytes for full speed devices and 1024 bytes for high speed devices (Section 5.6.3 of the USB 2.0 Specification.) To determine the exact value, one needs to identify the supported format and sample rate configuration that consumes the largest possible bandwidth for the endpoint.

The amount of audio data contained in each packet may vary depending on the speed of the device. If the device is full speed, each packet contains 1 millisecond (ms) of data. On high speed USB devices, each USB frame is split into eight 125 microsecond segments called microframes. Endpoints can specify the polling interval at which transfers can occur, i.e. every microframe, every other microframe, etc. This frequency must be taken into account when calculating the max packet size. (At this time, AppleUSBAudio supports at most one transaction per microframe. See the High Speed Streaming section for more information.)

Calculation Examples

The following full and high speed examples illustrate the calculation procedure:

A) 48 kHz / 24-bit / 2 channel / full speed

Each sample frame contains 2 channels of 3 byte samples which is 6 bytes per sample frame. The packet size is calculated as follows:

This value assumes that the data rate will never vary, as is the case when the stream is synchronous to SOF. If the endpoint is adaptive or asynchronous, one additional sample frame should be added to accommodate adjustments in the data rate. Section 2.3.1.1 of the Audio Data Formats 2.0 Specification limits variation in the packet size by +/- 1 sample frame.

Synchronous: Max packet size = 288 bytes

Adaptive or asynchronous: Max packet size = 288 + 6 = 294 bytes

B) 44.1 kHz / 16-bit / 8 channel / full speed

Each sample frame contains 8 channels of 2 byte samples which is 16 bytes per sample frame. The packet size is calculated as follows:

Packets cannot contain partial sample frames. So, while most packets will contain 44 sample frames, every tenth packet will contain 45 sample frames.

Synchronous, adaptive or asynchronous*: Max packet size = 720 bytes

*The extra permitted sample frame has already been included.

C) 192 kHz / 32-bit / 10 channel / high speed

This example assumes one transaction every microframe (i.e. the polling interval is 1 microframe.)

Each sample frame contains 10 channels of 4 byte samples which is 40 bytes per sample frame. The packet size is calculated as follows:

Synchronous:

Adaptive or asynchronous: Max packet size = 960 + 40 = 1000 bytes

How AppleUSBAudio Uses the Max Packet Size

When starting a stream, the driver reserves the minimum USB isochronous bandwidth possible: the minimum of the max packet size and the bandwidth required for the current sample rate and format. This maximizes the remaining available bandwidth for other USB devices, including other audio devices connected to the Mac. It also increases the likelihood that the bandwidth request will be granted in situations where much of the bandwidth is already in use.

Important Tips

When determining the max packet size, make sure not to forget the extra sample frame in the calculation for these special cases:

• Sample rates that do not divide evenly into packets (i.e. 44.1 kHz)

• Adaptive and asynchronous endpoints

When streaming, devices must always observe the bandwidth restrictions for each of the sample rate and format settings. This includes the +/- 1 sample frame rule in Section 2.3.1.1 of the Audio Data Formats 2.0 Specification.

Warning: Failure to comply with the bandwidth rules for the current sample rate and format may not only result in audio corruption for that particular stream, but for all of the other streams on the same engine.

USB Audio Controls

AppleUSBAudio parses the audio control interface descriptors to discover the audio topology for a USB audio device. The topology consists of building blocks or units that represent the audio function and provide a mechanism to manipulate parameters, like adjusting the audio controls. Figure 2 shows a simple topology that consists of Input and Output Terminals in blue, Feature Units in yellow, and a Selector Unit and a Mixer Unit in orange.

AppleUSBAudio uses the information contained in the audio topology to find a device’s input and output volume/mute controls, hardware play through controls, input selector, and even clock source options for USB Audio 2.0 devices. AppleUSBAudio exposes these controls to Core Audio as IOAudioControls. This section focuses on volume, mute, and play through controls specifically.

Feature Units contain volume and mute controls which can logically map to volume, mute, and hardware play through controls on the Mac. When AppleUSBAudio creates input and output stream volume and mute IOAudioControls, these appear in Sound Preferences and the Audio MIDI Setup (AMS) application. In the case of play through, a Feature Unit’s mute control appears as a “Thru” toggle in AMS only. The play through volume controls are also published by AppleUSBAudio but do not appear in AMS or the Sound Preferences pane. However, they can be accessed via the developer audio utility HALLab.

Important: Since play through volume is not accessible to the user in AMS, developers should set the device's play through volume control default to a reasonable level to ensure a good user experience.

Control Publishing Rules

Since multiple Feature Units can exist in an audio path, AppleUSBAudio uses a special algorithm to select the Feature Unit that contains the logical controls to expose to the Audio HAL. The algorithm seeks to accommodate the most common cases and to minimize undesirable side effects. The rules are as follows:

* Volume/mute for input sources: AppleUSBAudio will publish the controls contained in the Feature Unit closest to the selector unit on the Input Terminal side as shown in Figure 3.

Important: Volume and mute controls intended to control the same source should be contained in the same Feature Unit (i.e. do not separate volume and mute in two consecutive Feature Units.)

* Volume/mute for output sources: AppleUSBAudio will publish the controls contained in the Feature Unit closest to the Output Terminal as shown in Figure 4.

* Hardware play through with Mixer Unit in path: AppleUSBAudio will publish controls contained in a Feature Unit between the Input Terminal and the Mixer Unit. Searching from the Input Terminal to the Mixer Unit, the driver selects the first Feature Unit that isn't shared with another audio path. An example is shown in Figure 5.

Important: Play through controls cannot be shared with another audio path because this could result in unwanted side effects. For example, if a play through control is also contained in a record path, muting the play through control would also unintentionally mute the recording input.

* Hardware play through without Mixer Unit in path: AppleUSBAudio will publish controls contained in the Feature Unit closest to the Input Terminal that isn't shared with another audio path.

Status Interrupts

A status interrupt pipe can be used to inform the host that a setting has changed on the device. This feedback maintains synchronization between the Mac’s user interface and the device state. Currently, AppleUSBAudio updates certain audio controls on the Mac for interrupts originating from Feature, Selector and Clock units as described in Table 6.

Please refer to Section 3.7.1.2 of the USB Audio 1.0 standard and Section 6 of the USB Audio 2.0 standard for more information.

Descriptive Naming

Another way to improve the user experience with a USB audio class device on Mac OS X is to provide meaningful and descriptive device and channel names. The following sections will explain how to accomplish this with the device’s configuration descriptors.

Device Name

The device name will appear in many places on the Mac, including in Audio MIDI Setup, Sound Preferences, and in third party audio applications. Core Audio represents each engine as a device in the system. If an engine has a name, Core Audio will use that as the device name, otherwise it will use the USB device name. Figure 6 shows how AppleUSBAudio and Core Audio will determine the descriptive name assigned to the device, depending on the number of streams associated with the engine, and the presence of the control and stream interface names, and USB device name.

Channel Names

AppleUSBAudio supports the Audio Cluster Descriptors as described in section 3.7.2.3 “Audio Channel Cluster Format” of the USB Audio 1.0 specification and section 4.1 “Audio Channel Cluster Descriptor” in the USB Audio 2.0 specification. These descriptors allow device developers to name the channels in a stream, using either predefined names (such as “Front Left”, or “Low Frequency Effects”, etc.) or custom names. Listing 1 shows the descriptor fields of interest, as represented in AppleUSBAudio. Please refer to the USB Audio specification sections previously mentioned for a thorough explanation of the use of these fields.

Listing 1 Structure representing the Audio Cluster Descriptor in AppleUSBAudio

Audio Cluster Descriptors can be embedded in Input Terminal, Mixer, Processing, and Extension Unit descriptors. AppleUSBAudio searches for the Audio Cluster Descriptor on an audio path starting from the Output Terminal to the Input Terminal and uses the first one it finds.

Supported USB Audio 2.0 Features

AppleUSBAudio was enhanced in Snow Leopard to support many of the key features contained in the USB Class Definition for Audio Devices 2.0 specification. The following features are currently supported:

High Speed Streaming

(USB 2.0, Sections 5.6 and 9.6.6)

Mac OS X supports high speed streaming, up to 1024 bytes per microframe for each isochronous endpoint, including overhead.

Note: The actual bandwidth available for endpoints depends on the current available bandwidth on the USB bus.

For example, Snow Leopard (and later) is able to stream 10 channels of 32-bit audio at 192 kHz to and from a USB Audio 2.0 device. Additional information pertaining to isochronous data transfer can be found in the USB Device Interface Guide.

Interface Association Descriptor

(USB Audio 2.0, Section 4.6)

This required descriptor identifies an Audio Interface Collection. The interfaces grouped in the collection must be contiguously numbered and in the following order:

1. AudioControl Interface (mandatory)

2. AudioStreaming Interface(s)

3. MIDIStreaming Interface(s)

Clock Entities

(USB Audio 2.0, Sections 3.13.11, 4.7.2.1 - 4.7.2.3)

Clock Domains are described using the new 2.0 Clock Entities: Clock Source, Clock Selector, and Clock Multiplier. The AppleUSBAudio driver also supports the associated clock related AudioControl Requests as specified in Sections 5.2.5.1 through 5.2.5.3.

Unlike USB Audio 1.0 devices, the use of switching the Alternate Setting to control the sampling frequency is prohibited for USB Audio 2.0 devices. Instead, a Clock Source entity serves as the master clock for a clock domain, which can provide a sampling signal frequency. Clock Selectors enable both the host and the audio function to switch clock inputs. Figure 7 shows how a Clock Selector appears in AMS. The Clock Multiplier provides a mechanism to derive additional sampling frequencies within a clock domain that are synchronous to the input clock signal.

Status Interrupt Control Endpoint

(USB Audio 2.0, Section 4.8.2.1, 6)

AppleUSBAudio contains additional support for parsing the Interrupt Data Message Format in Section 6.1. The only additional 2.0 status interrupt support added to the driver was for the Clock Source unit.

AppleUSBAudio responds in various ways to an interrupt generated from a Clock Source unit that is currently driving the data rate. If the clock validity bit indicates the clock is invalid and the audio topology contains a Clock Selector, the driver searches for an alternate valid Clock Source and switches to that (as described in Table 6.) If the Clock Source is valid, then it assumes the sample rate has changed. In this case, it republishes the available rates and updates the current device sample rate on the host.

Ways to Extend the Class Driver

AppleUSBAudio was designed to allow for some vendor specific extensions. This gives developers the advantage of adding special features without having to maintain the basic feature set of a high performance audio driver.

One way to augment the behavior of the class driver is to provide a codeless kernel extension (kext) that overrides certain properties of a USB audio device. These properties include the USB device and interface names, localization bundle, Core Audio HAL plugin, providing access to a custom control panel via Audio MIDI Setup's 'Configure device...' option and more. This sample code illustrates the various properties that can be modified.

Another way to customize AppleUSBAudio is to add vendor specified DSP processing to input and/or output audio streams. Developers can create a custom USB audio plugin that performs audio signal processing only for their device. This mechanism can also be used to provide access to a custom control panel. In the initialization routine, call super::pluginSetConfigurationApp() with the control panel's application bundle ID.

Document Revision History

Copyright © 2013 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2013-06-03

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

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

Behringer Usb Audio Interface Driver For Mac

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.

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:

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

Usb Audio Mixer For Mac

• 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