USB Device Class Definition for Audio Devices
Release 2.0
May 31, 2006 16
2 Management Overview
The USB is very well suited for transport of audio ranging from low fidelity voice connections to high quality, multi-channel audio streams. The USB has become a ubiquitous connector on modern PC’s and is well-understood by most consumers today. As such, it has become the connector of choice for many peripherals and is indeed the simplest and most pervasive digital audio connector available today. With the advent of the High Speed USB, consumers can count on this medium to meet all of their audio needs today and into the future. Many applications from communications, to entertainment, to music recording and playback, can take advantage of audio features of the USB.
In principle, a versatile bus specification like the USB provides many ways to propagate and/or control digital audio. For the industry, however, it is very important that audio transport mechanisms be well defined and standardized on the USB. Only in this way can interoperability be guaranteed among the many possible audio devices on the USB. Standardized audio transport mechanisms also help to keep software drivers as generic as possible. The Audio Device Class described in this document satisfies those requirements. It is written and revised by experts in the audio field. Other device classes that address audio in some way should refer to this document for their audio interface specification.
An essential issue in audio is synchronization of the data streams. Indeed, the smallest artifacts are easily detected by the human ear. Therefore, a robust synchronization scheme on isochronous transfers has been developed and incorporated in the USB Specification. The Audio Device Class definition adheres to this synchronization scheme to transport audio data reliably over the bus.
This document contains all necessary information for a designer to build a USB-compliant device that incorporates audio functionality. It specifies the standard and class-specific descriptors that must be present in each USB audio function. It further explains the use of class-specific requests that allow for full audio function control. A number of predefined data formats are listed and fully documented. Each format defines a standard way of transporting audio over the USB. Provisions have been made so that vendor-specific audio formats and compression schemes can be handled.
Many of the changes introduced in Version 2.0 of the USB Specification for Audio Devices take advantage of the new features provided in the USB 2.0 Specification. With the additional bandwidth made available, high speed USB operation allows the transport of multiple channels of high bit rate audio. This expands the range of solutions provided by USB audio devices but also challenges the way in which they operate. In addition to supporting the additional bandwidth, the specification supports new codec types for consumer audio applications, provides numerous clarifications of the original specification and extensions to support various changes in the core specification. The changes are not generally backwards compatible to 1.0 because that would too severely limit this new class of devices.
2.1 Overview of Key Differences between ADC v1.0 and v2.0
The following list is not an exhaustive list of all changes that have been introduced. For complete information, refer to the full specification. Pay special attention to Sections 1 through 6!
• Complete support for high speed operation - no longer are audio class devices limited to full speed operation.
• The notion of physical and logical Audio channel clusters.
• The number of predefined spatial locations has increased. In addition, a virtual spatial location called Raw Data was introduced.
• Use of the interface association descriptor - The standard Interface Association mechanism is used to describe an Audio Interface Collection. The former class specific mechanism was deprecated.
• Descriptor updates: fixed offsets associated with many descriptors and enlarged three byte fields into four bytes.
• Extensive support for interrupts to inform the host about dynamic changes that occur on the different addressable Entities (Clock Entities, Terminals, Units, interfaces and endpoints) inside the audio function.
• More clarification text on the audio function.
USB Device Class Definition for Audio Devices
Release 2.0
May 31, 2006 17
• Audio Control Changes.
– Control attribute changes.
– Mixer Unit control request (set/get pairs changed).
– Many updates in the control descriptions.
• Added support for clock domains, clock description and clock control.
• Added additional Audio Controls inside a Feature Unit (Input, Gain, Input Gain Pad …)
• Added bit pairs in descriptors to indicate presence and programmability of every Control
• Prohibited the use of Alternate Setting switching to change sampling frequencies. Instead, Clock Entities are introduced that can be manipulated (through the AudioControl interface) to select operating sampling frequencies.
• Split off the examples in a separate document.
• Allowed binding between physical buttons on the audio function and the corresponding Audio Control. Prescribed how this is done.
• Added an Effect Unit to group algorithms that work on logical channels separately but require multiple parameters to manipulate the effect (as opposed to basic (single parameter) manipulation, performed in a Feature Unit).
• Introduced Parametric Equalizer Section Effect Unit.
• Rearranged Reverb, Modulation Delay and Dynamic Compressor PUs under the new Effect Unit.
• Added the concept of audio function Category. The Category indicates the primary use of the audio function as envisioned by the manufacturer.
• Added the Sampling Rate Converter Unit.
• Added a means to express Latency of individual building blocks within the audio function.
• Added Encoder support.
USB Device Class Definition for Audio Devices
3 Functional Characteristics
3.1 Introduction
In many cases, audio functionality does not exist as a standalone device. It is one capability that, together with other functions, constitutes a “composite” device. A perfect example of this is a DVD-ROM player, which can incorporate video, audio, data storage, and transport control. The audio function is thus located at the interface level in the device class hierarchy. It consists of a number of interfaces grouping related pipes that together implement the interface to the audio function.
An audio function is considered to be a ‘closed box’ that has very distinct and well defined interfaces to the outside world. Audio functions are addressed through their audio interfaces. Each audio function must have a single AudioControl interface and can have zero or more AudioStreaming and zero or more MIDIStreaming interfaces. The AudioControl (AC) interface is used to access the Audio Controls of the function whereas the AudioStreaming (AS) interfaces are used to transport audio streams into and out of the function. The MIDIStreaming (MS) interfaces can be used to transport MIDI data streams into and out of the audio function. The collection of the single AudioControl interface and the AudioStreaming and MIDIStreaming interfaces that belong to the same audio function is called the Audio Interface Collection (AIC). A device can have multiple Audio Interface Collections active at the same time. These Collections are used to control multiple independent audio functions located in the same composite device. An Audio Interface Collection is described through the standard USB Interface Association mechanism that expresses interface binding via the Interface Association Descriptor (IAD).
Note: All MIDI-related information is grouped in a separate document, Universal Serial Bus Device Class Definition for MIDI Devices that is considered part of this specification. The remainder of this document will therefore not mention MIDIStreaming interfaces and their specifics anymore.
The following figure illustrates the concept: Audio FunctionAudio-StreamingInterfaceINUSBAudio-StreamingInterfaceINAudio-StreamingInterfaceINAudio-StreamingInterfaceOUTAudio-StreamingInterfaceOUTAudio-StreamingInterfaceOUTAudioControl InterfaceAudio InterfaceCollectionAlternate Settings
Figure 3-1: Audio Function Global View
18
Release 2.0
May 31, 2006
USB Device Class Definition for Audio Devices
Release 2.0
May 31, 2006 19
All functionality pertaining to controlling parameters that directly influence audio perception (like volume)
are located inside the central rectangle and are exclusively controlled through the AudioControl interface.
Streaming aspects of the communication to or from the audio function are handled through separate
AudioStreaming interfaces. The AudioStreaming interface is primarily used for transporting audio data
between the audio function and the outside world. However, all control data that is related specifically to
the streaming behavior is also conveyed through the AudioStreaming interface. In particular, all control
data that is used to influence the decoder or encoder process that potentially resides between the actual
streaming endpoint and the audio function (e.g. conversion from AC-3 encoded stream to 5.1 physical
audio channels) is conveyed through the AudioStreaming interface.
Note that in some cases an AudioStreaming interface is only used to perform controlling functions while
no actual data is transported over the interface. A physical S/PDIF connection to the audio function is a
typical example. Although the actual audio data is coming in from the outside world (not through the
USB), it might be necessary to control some aspects of the S/PDIF connection. In that case, the S/PDIF
connection is represented by an AudioStreaming interface so that it becomes addressable through USB.
Also note that the connection between the AudioStreaming interfaces and the audio function is not ‘solid’.
The reason for this is that when seen from the inside of the audio function, each audio stream entering or
leaving the audio function is represented by a special object, called a Terminal (see further). The Terminal
concept abstracts the actual AudioStreaming interface inside the audio function and provides a logical view
on the connection rather than a physical view. This abstraction allows audio channels within the audio
function to be treated as ‘logical’ audio channels that do not have physical characteristics associated with
them anymore (analog vs. digital, format, sampling rate, bit resolution, etc.).
3.2 Audio Interface Collection (AIC)
On USB, an audio function is completely defined by its interfaces. An audio function has one
AudioControl interface and zero d into an Audio Interface
e
The Audio Function class and Subclasses can be further qualified by the Function Protocol code. The
ion sion of this specification so that enumeration
stantiated.
or more AudioStreaming interfaces, groupe
Collection. The standard USB Interface Association mechanism is used to describe the Audio Interface Collection i.e. to bind those interfaces together. Interface Association is expressed via the standard USB Interface Association Descriptor (IAD). Every Interface Association Descriptor has a FunctionClass, FunctionSubClass and FunctionProtocol field that together identify the function that is represented by thAssociation. The following paragraphs define these fields for the Audio Device Class. 3.3 Audio Function Class An Interface Association has a Function Class code assigned to it. This specification requires that the Function Class code be the same as the Audio Interface Class code.
The Audio Function class code is assigned by this specification. For details, see Appendix A.1, “Audio Function Class Code”. 3.4 Audio Function Subclass
The Audio Function class is divided into Function Subclasses. At this moment, the Function SubClass codeis not used and must be set to FUNCTION_SUBCLASS_UNDEFINED. The assigned codes can be found in A.2, “Audio Function Subclass Codes” of this specification. All other Subclass codes are unused and reserved by this specification for future use. 3.5 Audio Function Protocol
Funct Protocol code is used to reflect the current versoftware can decide which driver versions need to be in
The assigned Protocol codes can be found in Appendix A.3, “Audio Function Protocol Codes” of this specification. All other Protocol codes are unused and reserved by this specification for future use.
USB Device Class Definition for Audio Devices
Release 2.0
May 31, 2006 20
h USB belong to
this class.
t, f this class, the only requirement is that it exposes one
in
aming interfaces for consuming or
ss code is assigned by the USB. For details, see Appendix A.4, “Audio Interface
Class Code”.
re part of a certain Interface
• AudioStreaming Interface Subclass
ion.
the current version of this specification.
.
ion Category indicates the primary intended use for the audio function. The following
.
ne: A device set up to record audio from audible sources.
• Headset: A device with at least one speaker and at least one microphone designed to be worn or held
ck and voice input capabilities.
o another
converting audio data from one encoding format to another (e.g.
th at least one microphone and at least one speaker that is
d optical inputs and
outputs for connection to other devices.
3.6 Audio Interface Class The Audio Interface class groups all functions that can interact with USB-compliant audio data streams. All functions that convert between analog and digital audio domains can be part of this class. In addition, those functions that transform USB-compliant audio data streams into other USB-compliant audio data streams can be part of this class. Even analog audio functions that are controlled throug
In facor an audio function to be part of
AudioControl interface. No further interaction with the function is mandatory, although most functionsthe audio interface class will support one or more optional AudioStre
producing one or more isochronous audio data streams. The Audio Interface cla
3.7 Audio Interface Subclass The Audio Interface class is divided into Subclasses. All audio functions a
Subclass. The following three Interface Subclasses are currently defined in this specification: • AudioControl Interface Subclass
• MIDIStreaming Interface Subclass
The assigned codes can be found in Appendix A.5, “Audio Interface Subclass Codes” of this specificatAll other Subclass codes are unused and reserved by this specification for future use.
3.8 Audio Interface Protocol The Audio Interface class and Subclasses can be further qualified by the Interface Protocol code. The
Interface Protocol code is used to reflect
The assigned codes can be found in Appendix A.6, “Audio Interface Protocol Codes” of this specificationAll other Protocol codes are unused and reserved by this specification for future use. 3.9 Audio Function Category The Audio Funct
Function Categories are currently defined in this specification: • Desktop Speaker: One or more speakers set up in a small environment to provide audio intended primarily for one person.
• Home Theater: Several speakers set up in a moderately sized environment to provide audio levels significantly louder than a Desktop Speaker setup and intended to be clearly heard by multiple people• Micropho
by a user to provide personal audio playba•
Telephone: A Headset or handset type device that also connects to a telephone system, (e.g. POTs, PBX, VoIP) capable of making and receiving telephone calls. • Converter: A device that allows conversion of audio from one electrical or optical format t
electrical or optical format, and/or
AC-3 to PCM, etc.).
• Voice/Sound recorder: A device set up wi
designed to operate, at least some of the time, independently of the Host to record and store audible sources and play back its recorded content. • IO Box: A device designed to deliver one or more, possibly different, electrical an
最終更新：2011年05月08日 13:36
