USB Audio Class 2.0 Device Specification Release

5星 · 超过95%的资源需积分: 10 152 浏览量更新于2024-07-25 收藏 2.1MB PDF 举报

USB Audio Class (UAC) 是Universal Serial Bus (USB) 设备类定义的一个关键部分，专为音频设备设计，旨在提供统一的接口标准，以便不同制造商的音频设备能在USB连接下顺畅交互。UAC Release 2.0，发布于2006年5月31日，标志着这一规范的进一步发展和完善。 UAC 2.0的主要目标是确保音频数据在USB总线上的高效传输，同时提供高质量的声音性能和电源管理功能。它定义了音频设备与主机之间的通信协议，包括音频数据流的传输、控制信号的交换、以及设备的配置和状态管理。这个版本的贡献者来自多个知名公司，如Philips Applied Technologies、Roland Corporation、Creative Labs、Microsoft Corporation等，表明了该标准得到了行业内的广泛认可和支持。 UAC 2.0的范围包括了音频接口的详细规格，如音频流的封装和解封装、同步控制、音频格式支持（如WAV、MP3等）、数字音频路径、音频缓冲管理、以及设备的音频增强功能等。它还规定了如何处理多通道音频，如立体声或环绕声，以及如何在USB低功耗模式下维持音频质量。在文档修订历史中，从最初的1.7版本到1.7a版本，可以看到持续的改进和反馈整合。这反映了USB-IF（USB Implementers Forum）对标准的不断优化，以适应技术进步和市场需求的变化。 UAC 2.0的实现不仅提高了音频设备的易用性，也促进了USB设备的普及和兼容性。对于音频开发者来说，理解和遵循UAC规范至关重要，因为它影响着产品的设计和用户体验。同时，对于消费者而言，这意味着可以期待在各种USB接口的设备上获得一致且高质量的音频体验。 UAC Release 2.0是USB音频设备开发的重要参考，它推动了音频设备技术的发展，为现代电子设备中的音频功能奠定了坚实的基础。

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

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 Function

Audio-

Streaming

Interface

USB

Audio-

Streaming

Interface

Audio-

Streaming

Interface

Audio-

Streaming

Interface

OUT

Audio-

Streaming

Interface

OUT

Audio-

Streaming

Interface

OUT

AudioControl Interface

Audio Interface

Collection

Alternate 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

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 th

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

is 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 ver

software 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

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 fac or an audio function to be part of

AudioControl interface. No further interaction with the function is mandatory, although most functions

the 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 specificat

All 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 specification

All 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

剩余143页未读，继续阅读

iorysun

粉丝: 0
资源: 11

USB Audio Class 2.0 Device Specification Release

usb_audio+cdc复合设备驱动.rar

aduio视频监控

aduio recognition

gupnp-av(aduio&video)

ex_aduio.zip_ wm8978 mp3_8978_WM8978 sch_mp3 to wav_stm32 wm8978

xine-lib-1.1.8.tar.gz_LINUX lib_mpeg-1 aduio lin_xine-0.2.3.ta

vue的 aduio

vue-aduio-player

aduio stream period_size

基于python与Django的网上购物平台

最新资源