Introduction

在许多情况下，音频功能不作为独立设备存在。它是一种能力，与其他功能一起构成了一个“复合”设备。一个很好的例子 DVD-ROM 播放器就是音频、数据存储和传输控制功能的集合。音频功能因此位于设备类层次结构中的接口级别。它由多个接口组成，共同实现音频功能的接口。

音频功能被认为是一个“closed box”，具有非常独特的和定义良好的接口到 outside world。音频功能通过它们的音频接口进行寻址。每个音频功能都必须有一个 AudioControl 接口可以有 0 个或多个 AudioStreaming 和 0 个或多个 MIDI Streaming 接口。AudioControl（AC）接口用于访问 function 的音频控件，而 AudioStreaming (AS) 接口用于将音频流传入和传出 function。 MIDI streaming (MS) 接口可用于将 midi 数据流传输到和输出音频功能。单个 AudioControl 接口以及属于同一音频功能的 AudioStreaming 和 MIDI Streaming 接口的集合称为 Audio Interface Collection（AIC）。一个设备可以同时激活多个音频接口集合（AIC）。这些集合用于控制位于同一 composite device 中的多个独立音频功能。通过标准 USB 接口关联机制来描述音频接口集合，通过接口关联描述符 (IAD) 来表示接口绑定。

注：所有与 MIDI 相关的信息被分组在一个单独的文档中，MIDI 设备的通用串行总线设备类定义被认为是本规范的一部分。因此，本文档的其余部分将不再提及 MIDI Streaming 接口及其细节。下图说明了这个概念：

所有与直接影响音频感知（如音量）的控制参数相关的功能都位于中央矩形内，并仅通过 AudioControl 接口进行控制。通过单独的 AudioStreaming 接口处理与音频功能之间的流媒体通信。AudioStreaming 接口主要用于在 Audio function 和 outside world 之间传输音频数据。但是，所有与流行为具体相关的控制数据也通过 AudioStreaming 接口进行传输。特别是，所有用于影响解码器或编码器过程的控制数据，可能驻留在实际流端点和音频功能之间（例如，从 AC-3 编码流到 5.1 物理音频通道的转换）通过 AudioStreaming 接口传送。

请注意，在某些情况下，Audiostreaming 接口仅用于执行 controlling functions，而不会通过该接口传输实际数据。与 S/PDIF 连接就是一个典型的例子。虽然实际的音频数据是从外部输入的（不是通过 USB)，但可能需要控制 S/PDIF 连接的 aspects。在这种情况下，S/PDIF 连接由 AudioStreaming 接口表示，这样它就可以通过 USB 寻址。

还要注意的是，AudioStreaming 接口和音频功能之间的连接不是“solid”。这样做的原因是当从 audio function 内部看时，每个进入或离开音频函数的音频流都由一个称为 Terminal 的特殊对象表示（见下文）。Terminal 概念抽象了音频功能内部的实际 Audio Streaming 接口，并提供了连接的逻辑视图，而不是物理视图。这种抽象允许音频函数中的音频通道被视为不再具有与之相关的物理特性的逻辑“音频通道”。（模拟量与数字、格式、采样率、位分辨率等）。

Audio Interface Collection

在 USB 上，音频功能完全由其接口定义。一个音频函数有一个 AudioControl 接口和零个或多个 AudioStreaming 接口，它们组成一个音频接口集合。标准的 USB 接口关联机制用于描述音频接口集合，即将这些接口绑定在一起。接口关联通过标准 USB 接口关联描述符 (IAD) 表示。每个接口关联描述符都有一个 FunctionClass、FunctionSubClass 和 FunctionProtocol 字段，它们共同标识由关联表示的函数。以下段落定义音频设备类的这些字段。

Audio Function Class

接口关联被分配了一个 Function Class code。该规范要求函数类代码与音频接口类代码相同。音频函数类代码由本规范指定。有关详细信息，请参见附录 A.1“音频函数类代码

Audio Function Subclass

音频函数类分为函数子类。此时，Function SubClass 代码未被使用，必须设置为 FUNCTIONSUBCLASSUNDEFINED 分配的代码可以在本规范的 A.2“音频功能子类代码”中找到。

Audio Function Protocol

音频函数类和子类可以由函数协议代码进一步限定。函数协议代码用于反映本规范的当前版本，以便枚举软件可以决定需要实例化哪些驱动程序版本指定的协议代码可以在本规范的附录 A.3“音频功能协议代码”中找到。

Audio Interface Class

音频接口类将所有可以与 USB 兼容的音频数据流交互的功能分组。在模拟和数字音频域之间转换的所有函数都可以是此类的一部分。此外，那些将符合 USB 的音频数据流转换成其他符合 USB 的音频数据流的函数也属于此类。即使是通过 USB 控制的模拟音频功能也属于此类。

事实上，要使音频函数成为此类的一部分，唯一的要求是它公开一个 AudioControl 接口。虽然音频接口类中的大多数函数将支持一个或多个可选的 AudioStreaming 接口，用于消费或产生一个或多个等时音频数据流，但与该函数的进一步交互是强制性的。

音频接口类代码由 USB 分配。有关详细信息，请参见附录 A.4“音频接口类代码”

Audio Interface Subclass

音频接口类分为子类。所有音频功能都是某个接口子类的一部分。本规范中目前定义了以下三个接口子类：

AudioControl Interface Subclass
AudioStreaming Interface Subclass
MIDIStreaming Interface Subclass

指定的代码可以在本规范的附录 A.5“音频接口子类代码”中找到。

Audio Interface Protocol

音频接口类和子类可以由接口协议代码进一步限定。接口协议代码用于反映本规范的当前版本。指定代码可以在附录 A.6“音频接口协议代码”中找到。

Audio Function Category

音频功能类别指示音频功能的主要预期用途。本规范中目前定义了以下功能类别：

Desktop Speaker: 在小型环境中设置的一个或多个扬声器，主要供一个人使用的音频。
Home Theater: 在中等大小的环境中设置多个扬声器，以提供比桌面扬声器设置更大的音频电平，并旨在让多人清楚地听到。
Microphone: 一种装置，设置成从可听的来源录制音频。
Headset: 具有至少一个扬声器和至少一个麦克风的设备，以提供个人音频播放和语音输入功能。
Telephone: 也连接到电话系统（例如 POT、PBX、VolP) 的耳机或手持设备，能够拨打和接听电话
Converter: 允许音频从一种电或光格式转换为另一种电或光格式，或将音频数据从一种编码格式转换为另一种编码格式（例如 AC-3 转换为 PCM 等）的设备。
Voice/Sound recorder: 至少有一个麦克风和至少一个扬声器的设备，其设计目的是至少在某些时候独立于主机来记录和存储声音源并播放其记录的内容。
I/O Box: 设计用于提供一个或多个可能不同的电气和光学输入和输出以连接到其他设备的设备
Musical Instrument: 如钢琴、吉他、合成器、鼓机等。
Pro-Audio: 音频消费者通常不使用的设备，例如编辑设备、多轨录音设备等
Audio/Video: 来自同时提供视频的设备的音频，期望音频与视频紧密耦合，例如便携式摄像机、DVD 播放器电视机等。
Control Panel: 用于控制通过音频设备系统的音频流的设备，如混音器面板。
Other: 任何器械，其主要用途与上述描述有足够的不同，以至于被认为是一种完全不同形式的器械

指定的代码可在本规范附录 A.7“音频功能类别代码”中找到。

Clock Domains

时钟域被定义为一个区域，在该区域内所有采样时钟都来自同一个主时钟。因此，在同一时钟域内，所有采样时钟是同步的，它们的时序关系是恒定的。然而，采样时钟可以在不同的采样频率。主时钟可以通过许多不同的方式产生。内部晶体可以是主时钟，可以使用 USB 帧起始 (SOF) ，或者甚至可以使用外部提供的时钟作为主时钟。一般来说，同一音频功能中可以存在多个不同的时钟域。

Audio Synchronization Types

AudioStreaming 接口中使用的每个同步音频端点都属于 USB 规范第 5 节中定义的同步类型。以下各节简要介绍可能的同步类型。

Inter Channel Synchronization

处理音频（尤其是 3-D 音频）时的一个重要问题是不同物理音频通道之间的相位关系。

为了向主机提供一个可管理的相位模型，需要一个音频功能来报告每个 Audiostreaming 接口的内部延迟。这种延迟以（微）帧数表示，这是由于音频功能必须缓冲至少一个（微）帧的采样值，以有效地消除（微）帧内的数据包抖动。此外，一些音频函数将引入额外的延迟，因为它们需要时间来正确地解释和处理音频数据流（例如，压缩和解压缩）。

Audio Function Topology

为了能够操作音频功能的物理属性，它的功能必须被划分为可寻址的实体。两种类型的这种通用实体被识别，并被称为 Unit 和 Terminals。此外，还定义了一种特殊类型的实体这些实体被称为 Clock Entities，它们用于描述和操作音频函数内部的时钟信号。

Unit 提供了基本的 building blocks 来充分描述大多数音频功能。音频功能是通过连接这些 Unit 中的几个来构建的。一个 Unit 有一个或多个输入 Pins 和一个输出 Pin，其中每个 Pins 代表音频功能内的逻辑音频通道簇（请参见第 3.13.1 节"音频通道簇”》。根据所需的拓扑结构，Unit 通过连接其 I/0 Pins 连接在一起。请注意，将一个实体的输出 Pins 连接到位于不同其他实体上的多个输入 Pins 是完全合法的，有效地创建了一个一对多连接。

此外，还引入了 Terminals 的概念。有两种类型的 Terminals。Input Terminals (IT) 是表示音频功能内部音频通道的起点的实体。Output Terminals (OT) 表示音频通道的结束点。从音频功能的角度来看 USB 端点是输入或输出端子的典型示例。它或者向音频功能 (IT) 提供数据流，或者消耗来自音频功能 (OT) 的数据流。

一个 Unit 的输入 Pins 编号从 1 开始到 Unit 上的输入 Pins 总数。输出 Pins 号始终为 1。Input Terminals 只有一个输出 Pins，其数量总是一个。Output Terminals 只有一个输入 Pins 永远都是 1。

音频功能中的每个 Unit 都由其关联的单元描述符 (UD) 完整描述。单元描述符包含识别和描述 Unit 所需的所有字段。同样，音频函数中的每个 Terminals 都有一个 Terminals 描述符 (TD)。此外，这些描述符还提供了有关音频功能的拓扑结构的所有必要信息。它们充分描述了 Terminals 和 Unit 是如何相互连接的。

本规范描述了以下八种不同类型的标准 Unit 和 Terminals，被认为足以代表当今和不久的将来可用的大多数音频功能：

Input Terminal (IT)
Output Terminal (OT)
Mixer Unit (MU)
Selector Unit (SU)
Feature Unit (FU)
Sampling Rate Converter Unit
Effect Unit (EU)
Processing Unit (PU)
Extension Unit (XU)

除了 Unit 和 Terminals 之外，还引入了时钟实体的概念。本规范定义了三种类型的时钟实体：

Clock Source (CS)
Clock Selector (CX)
Clock Multiplier (CM)

时钟源为音频功能的全部或部分提供一定的采样时钟频率。时钟源可以代表一个内部采样频率发生器，但也可以代表一个外部采样时钟信号输入到音频功能。时钟源有一个时钟输出 Pins，该 Pins 携带由时钟源表示的采样时钟信号。时钟输出 Pins 数始终为 1。时钟选择器用于在音频功能内部可能提供的多个采样时钟信号之间进行选择。它有多个时钟输入 Pins 和一个时钟输出 Pins。时钟输入 Pins 的编号从 1 到时钟选择器上时钟输入 Pins 的总数。

时钟 Multiplier 用于在其单个时钟输入引脚处获得与时钟信号频率不同的新时钟信号。它通过将时钟信号频率乘以分子 P，再除以分母 Q. 对于给定的时钟 Multiplier，P 和 Q 值是固定的。保证新的时钟信号与输入时钟信号同步。时钟 Multiplier 有一个输入 Pins 和一个输出 Pins，它们的数字总是一个。

通过使用时钟源、时钟选择器和时钟 Multiplier 实体的组合，可以将最复杂的时钟系统表示出来，并将其暴露在主机软件中。

时钟输入和输出 Pins 与为单元和端子定义的输入和输出 Pins 有本质的区别。时钟 Pins 只携带时钟信号，因此不能连接到 unit 或 Terminals 输入和输出 Pins。它们仅用于表示时钟电路拓扑。每个输入和输出 Terminals 具有连接到时钟实体的时钟输出 Pins 和单个时钟输入 Pins。时钟输出 Pins 所携带的时钟信号决定了 Terminals 所代表的硬件工作的采样频率。每个采样速率转换器单元有两个时钟输入 Pins，通常连接到两个不同时钟实体的时钟输出 Pins。这些时钟输出 Pins 携带的时钟信号决定采样率转换单元转换的采样频率。

每个时钟实体由时钟实体描述符 (CED) 描述。时钟实体描述符包含识别和描述时钟实体的所有必要字段。描述符将在本文档第 4 节“描述符”中进一步详细介绍。单元描述符、终端描述符和时钟实体描述符的集合为主机提供了音频功能的完整描述。此信息通常在枚举时从设备中检索。通过解析描述符，通用音频驱动程序应该能够完全控制音频功能（扩展单元表示的功能除外）。

完整的音频功能描述符集仅提供音频功能的静态初始描述。在操作过程中，可能会发生许多事件，迫使音频功能改变其状态。必须将这些更改通知主机软件，以便始终与音频功能保持”同步”一个广泛的中断机制已经到位，以报告任何和所有的状态变化的主机软件。

如图 3-2 所示，“音频内部功能”说明了上面定义的概念。使用进一步定义的图标符号，它描述了一个假想的包含 16 个实体的音频功能：3 个输入端子、5 个单元、3 个输出端子、2 个时钟源、1 个时钟选择器和 2 个时钟 Multiplier。每个实体都有其唯一的 ID（从 1 到 16) 和描述符，该描述符充分描述了实体的功能以及该特定实体如何连接到音频功能的整体拓扑中。

输入端子 1(IT1) 可以表示用于将音频从主机流式传输到音频设备的 USBOUT 端点；IT2 可以是一个模拟的表示音频设备上的 Line-IN 连接器；IT3 可以是音频设备上的模拟麦克风输入连接器。选择器单元 4(SU4) 在来自主机的音频和 Line in 连接器上的音频之间进行选择。特征单元 5(FU 5) 被用来控制音频（音量，低音，高音··.)，然后将其提供给输出端子 9(OT9)。 OT9 可以是音频设备上的耳机输出插孔的表示。

(USB OUT、Line In 和 MicIn) 连接到混音器单元 6 (MU 6)。然后，混音器的输出被送入处理单元 7 (PU 7)，它可以对混音执行一些音频处理算法。结果又被发送到 FU8，在那里对音频（音量。..) 进行一些最后的调整。FU 8 与 OT10 和 OT11 相连。OT10 可以表示集成到音频设备中的扬声器，OT11 可以表示用于将处理后的音频发送到主机以进行录制的 USBIN 端点。

时钟源 12(CS12) 可以表示内部采样频率发生器，例如以 96 kHz 运行。时钟源 15(CS15) 可以是外部主采样时钟输入的表示，其可以用于将设备同步到外部源。时钟选择器 13(CS13) 可在两个可用时钟源之间进行选择。CS13 的输出为 IT1 IT2 IT3、OT10 和 OT11 提供 96kHz 的采样频率。时钟 Multiplier CM14 进一步将该时钟信号乘以 0.5，为 OT9 提供 48kHz 的采样频率以驱动耳机。由于音频功能中使用的所有采样频率始终来自单个主时钟（内部或外部），因此音频功能中的所有音频流都是同步的。

有关描述符内容的进一步详细信息，请参阅本文档的第 4 节“描述符”

在实体内部，通过音频控件进一步描述功能。控件通常提供对特定音频或时钟属性的访问。每个 Control 都有一组属性，这些属性可以被操作，或者提供有关控件行为的附加信息。控件可以具有以下属性：

Current setting attribute
Range attribute triplet consisting of: • Minimum setting attribute • Maximum setting attribute • Resolution attribute

例如，考虑要对单元内的音量控制。通过发出适当的 Get 请求，主机软件可以获得音量控制的属性值，例如，使用它们在屏慕上正确显示控制。设置音量控制的当前属性允许主机软件更改音量控制的音量设置。此外，音频函数中的每个实体都可以具有内存空间属性。该属性可选地提供对 Entity 的内部内存空间的通用访问。这可以用于通过一般提供的访问来实现特定于供应商的实体控制。

Audio Channel Cluster

音频通道簇是一组承载紧密相关的同步音频信息的音频通道。在音频功能内部，完全抽象了通过终端和单元之间的连接传输的音频数据的实际物理表示形式，集群中的每个音频通道被认为是一个逻辑通道以及该通道的所有物理属性（位宽、位分辨率等）。

集群中的通道编号从通道 1 开始，一直到集群中的通道数。虚拟通道零是用来解决一个单位（如果存在）的主控制，有效地影响所有的渠道。注意主控制（如果存在的话）必须与每通道控制分开来实现。更改主控件的设置不会影响任何单个通道控件的设置。音频通道群集中独立通道的最大数量限制为 255（通道零用于引用主通道）。在许多情况下，音频集群中的每个通道都与侦听空间中的某个位置相关联。这方面的一个简单示例是包含左右音频通道的群集。为了能够以可管理的方式描述更复杂的情况，本规范对音频通道簇中通道的顺序施加了一些限制和约束。为了支持在连接上流动的信息不能被解释为逻辑音频通道的集群的情况下，本规范定义了一个额外的虚拟空间位置，称为原始数据。此空间位置与本规范中定义的所有其他空间位置相互排斥。它不能与其他空间位置共存于同一集群中，其使用受到很大的限制。它只能用于不操作音频内容的实体之间的连接。这些实体只能是输入端子和输出端子。禁止对原始数据虚拟空间位置的所有其他使用。有 28 个预定义的空间位置 (27+1 个虚拟）:

Front Left - FL
Front Right - FR
Front Center - FC
Low Frequency Effects - LFE
Back Left - BL
Back Right - BR
Front Left of Center - FLC
Front Right of Center - FRC
Back Center - BC
Side Left - SL
Side Right - SR
Top Center - TC
Top Front Left - TFL
Top Front Center - TFC
Top Front Right - TFR
Top Back Left - TBL
Top Back Center - TBC
Top Back Right – TBR
Top Front Left of Center – TFLC
Top Front Right of C
Left Low Freque
Right Low Frequen
Top Side Left – TSL
Top Side Right – TSR
Bottom Center – BC
Back Left of Center – BLC
Back Right of Center – BRC
Raw Data – RD

如果音频通道簇中存在与某些先前定义的空间位置相对应的通道，则它们必须按照上述列表中指定的顺序出现。例如，如果一个群集包含前左、前右和 LFE 通道，则通道 1 是前左，通道 2 是前右，通道 3 是 LFE。

音频通道群集仅具有两个属性

群集中的音频通道数
群集中每个音频通道的空间位置，可以是预定义的（前左、前右、后左、LFE 等），也可以是自定义的。注：自定义也可用于指定与任何空间位置不直接相关的通道分配。一个简单的通道枚举模式（通道 1、通道 2 等）就是一个典型的例子。

每个音频通道群集都有一个群集描述符 (CD)，它完全描述了群集。本规范中使用了两种类型的音频通道集群：

逻辑音频通道簇描述音频功能（封闭框）内的音频数据，其中音频通道被视为逻辑概念。
物理音频通道簇描述 AudioStreaming 接口中的音频数据，该接口处理音频流中的实际物理音频通道（离散或编码）。

Mapping between Physical and Logical Audio Channel Clusters

AudioStreaming 界面可以有多个备用设置，每个设置代表界面的不同“操作模式”。例如，表示外部 S/PDIF 连接的 AudioStreaming 接口可以有一个备用设置，用于 S/PDIF 连接携带 Stereo PCM 数据时（两个通道）和另一个备用设置，当 AC-3 编码的信息通过 S/PDIF 连接 (6 个通道）传送时使用。因此，从一个备用设置切换到另一个可以有效地更改接口中实际音频通道的数量，还可能更改这些通道的空间位置。 AudioStreaming 接口与音频函数中相应的 Terminal 之间存在一对一关系。但是，AudioStreaming 界面可以有多个备用设置，每个备用设置具有不同的物理音频通道群集必须能够将每个物理音频通道簇映射到通过相应终端显示的单个逻辑音频通道簇上。因此，逻辑音频通道群集本质上是动态的，并且在为 AudioStreaming 接口选择不同的备用设置时可能会发生更改。当前的逻辑音频通道集群可以通过终端上的获取集群控制请求（如果实现的话）来检索。或者，主机软件可以跟踪当前处于活动状态的备用设置，并从该备用设置中检索物理音频通道簇描述，并将其用作逻辑通道簇定义。

Input Terminal

输入端子 (IT) 用于音频功能的“outside world”和音频功能中的其他单元之间的接口。它作为音频信息流入音频功能的容器。

输入端子可以代表除 USB OUT 端点之外的音频功能的输入，音频设备上的 Line in 连接器就是此类非 USB 输入的示例。但是，如果音频流通过 USB OUT 端点进入音频功能，则包含该端点的 AudioStreaming 接口与其关联的输入端子之间存在一对一的关系。特定于类的接口描述符包含一个字段，该字段保存对此输入终端的直接引用。主机需要同时使用音频流接口和端点描述符以及输入终端描述符，以充分了解输入终端的特性和功能。与流相关的参数存储在 AudioStreaming 描述符中。控制相关参数存储在 Terminal Deserintor 中。

从传入的（可能是编码的）音频流到逻辑音频通道的转换过程总是涉及到某种解码引擎。本规范定义了几种类型的解码（参见第 3.14 节“编码器和解码器”)。这些解码类型的范围从相当琐碎的解码方案，如将交错的立体声 16 位 PCM 数据转换为左和右逻辑通道，到非常复杂的方案，如将 MPEG-27.1 编码的音频流转换为左前，前左中心，前中心，前右中心前右，后左，后右和低频效果逻辑通道。解码引擎被认为是实体的一部分，它实际上接收编码的音频数据流（类似于 USBAudiostreaming 接口）。因此，解码类型隐含在 bmFormats 值中，该值位于特定于类的 AudioStreaming 接口描述符中。特定于解码引擎的请求必须指向 Audiostreaming 接口。相关联的输入端在逻辑信道被解码后处理它们。

输入端子具有单个时钟输入 Pins。该 Pins 上的时钟信号用作由该输入端子表示的所有底层硬件的采样时钟。在输入端子描述符中有一个字段唯一标识输入端子所连接的时钟实体。输入端子的符号如下图所示：

Output Terminal

输出终端 (OT) 用于音频功能内部的单元与“outside world”之间的接口。它作为音频信息的出口，流出音频功能。它的功能是在输出音频数据从原始独立的逻辑通道正确打包到输出音频流（编码过程）之前，表示输出音频数据的接收器。音频通道群集通过单个输入 Pins 进入输出端子。

输出端子可以表示除 USB IN 端点之外的音频 Function 的输出。内置于音频设备或 Line Out 连接器中的扬声器就是这种非 USB 输出的示例。但是，如果音频流通过 USB IN 端点离开音频 Function，则包含此端点的 Audiostreaming 接口与其关联的输出端子之间存在一对一关系。特定于类的接口描述符包含一个字段，该字段保存对此输出终端的直接引用。主机需要同时使用 AudioStreaming 接口和端点描述符以及输出终端描述符，以充分了解输出终端的特性和功能。与流相关的参数存储在 Audiostreaming 描述符中控件相关的参数存储在 Terminal 描述符中。

从传入的逻辑音频通道到可能编码的音频流的转换过程总是涉及到某种编码引擎。本规范定义了几种类型的编码（见第 3.14 节“编码器和解码器”)，范围从简单的到非常复杂的方案。编码引擎被认为是实体的一部分，它实际上传输编码的音频数据流（类似于 USBAudiostreaming 接口）。因此，编码类型隐含在 bmFormats 值中，该值位于特定于类的 AudioStreaming 接口描述符中。特定于编码引擎的请求必须是指向 AudioStreaming 接口。相关联的输出终端在编码之前处理逻辑通道

输出端子具有单个时钟输入引脚。该引脚上的时钟信号用作由该输出端子表示的所有底层硬件的采样时钟。在输出终端描述符中有一个字段，它唯一地标识输出终端连接到的时钟实体输出端子的符号如下图所示

Feature Unit

特征单元 (FU) 本质上是一个多通道处理单元，它提供对传入逻辑通道上的多个单参数音频控件的基本操作。对于每个逻辑通道，功能单元可选地为以下功能提供音频控制：

Mute
Volume
Tone Control(Bass, Mid, Treble)（音调控制）
Graphic Equalizer（图像均衡器）
Automatic Gain Control（自动增益控制）
Delay
Bass Boost（低音增强）
Loudness（响度）
Input Gain
Input Gain Pad
Phase Inverter（反相器）

此外，功能单元可选择提供上述音频控制，但现在可同时影响集群的所有通道。通过这种方式可以实现“主”控件。主控制在各个通道控制之后级联。此设置在多通道系统中特别有用，其中单个通道控件可用于通道平衡，主控件可用于整体设置。集群中的逻辑信道的编号从 1 到集群中信道的总数。主通道的通道号为零，实际上总是存在的。

特征单元描述符报告了特征单元中每个通道和主通道的控制。所有单元中的逻辑通道都完全独立，特征单元内的通道之间不存在交叉耦合。逻辑输出通道和输入通道一样多。这些被组合成一个音频通道簇，通过一个输入引脚进入功能单元，并通过一个输出引脚离开单元。特征单元的符号如下图所示：

Feature Unit 与 HID 对比

Binding between Physical Buttons and Audio Controls

大多数包含音频功能的设备也会有一个或多个 frontpanel buttons，用于控制设备内音频功能的某些方面。最明显的例子是多媒体扬声器前面的音量控制按钮。由于音频功能可能包含许多相同类型的音频控件，因此需要将物理控件（按钮、旋钮、滑块、点动等）绑定到音频功能中的特定音频控件。本规范提供了两种互斥的方法来提供这种绑定：

物理按钮实现为 HID 控件
物理按钮是音频控制的集成部分

禁止对同一个物理按钮实现这两种方法。但是，允许对某些 frontpanel buttons 使用第一种方法，对其余 frontpanel buttons 使用第二种方法。强烈建议不使用上述两种方法实现前面板按钮，即对主机软件不可见且仅具有局部效果的按钮。

Physical button is a HID Control

HID 是 USB 设备中的一种设备类型，他与 UAC 之间并没有直接的关联性，两者是完全独立的，只是 HID 设备包括鼠标、键盘、遥杆等具有通过 USB 控制 host 的声音的设备，可以通过实现这些设备的描述符实现对 host 的音量控制，这样就可以用来控制 UAC 的音量。

在这种情况下，物理按键与音频功能完全分离，并在设备的 HID 接口内实现。音频功能甚至不知道按钮的存在。按钮的任何状态变化都通过 HID 报告传送给主机软件。然后由主机软件来解释按钮状态的变化，并从那里获得对音频功能要采取的适当行动。因此，绑定责任完全属于应用程序或操作系统软件。尽管此方法提供了广泛的灵活性但它也给软件带来了提供正确绑定的负担。

Physical button is Integral Part of the Audio Control

而 Feature Unit 是 UAC 标准里定义的特性单元，功能更强大可以实现对每个逻辑通道提供音频控制，包括但不限于 mute 和 volume。

在这种情况下，物理按键直接与实际的音频控制交互。按钮状态更改不会报告给主机软件。相反，由按钮操作引起的音频控制的状态变化通过音频控制中断机制报告给主机软件。因此，物理按钮和 Audio 控件之间的绑定非常直接，完全由设备的设计决定。尽管不太灵活，但该方法提供了一种非常清晰和直接的方式来执行绑定。

Encoders and Decoders

每当音频数据流进入或离开音频 Function 时，都涉及到某种解码或编码过程。这个过程可以是相当琐碎的（交织或解交织样本），但也可以是相当复杂的。

在某些情况下，主机软件和编码或解码过程之间的交互是必要的。此时定义了五个这种类型的编码器和解码器进程：

MPEG Encoder and Decoder
AC-3 Encoder and Decoder
Windows Media Audio (WMA) Encoder and Decoder
DTS Encoder and Decoder
OTHER Encoder and Decoder

这些进程各自定义了特定的控件，允许操纵或监视编码器或解码器进程的内部状态。这些控件是通过编码器或解码器所属的 AudioStreaming 接口寻址的。

Copy Protection

由于音频设备类主要处理数字音频流，因此不能忽视保护这些通常受版权保护的流的问题。因此，本规范提供了保存任何可用的版权信息的方法。然而，管理整个音频功能的复制保护信息流是主机软件的责任。每当数字音频流进入或离开音频功能时，复制保护问题就会出现。因此，复制保护机制是在音频功能的终端级实现的。进入音频功能的流可以伴随着特定的信息，描述该音频流的复制保护级别。同样，如果硬件允许的话，离开音频功能的流应该伴随着适当的复制保护信息。该规范提供了两个专用请求，可用于管理复制保护机制。 GetCopy Protect 请求可用于从输入端检索复制保护信息，而 Set Copy Protect 请求可用于预设输出端的复制保护级别。本规范提供了三个级别的拷贝许可，类似于 CGMS（拷贝生成管理系统）和 SCMS （串行拷贝管理系统）。

Level 0: 不受限制地允许复制。该材料要么没有版权，要么没有主张版权。
Level 1: 可以制作一个副本。材料受版权保护，为原创。
Level 2: 材料受版权保护，不允许数字拷贝

Operational Model

一个设备可以支持多种配置。在每个配置中可以有多个接口，每个接口都可能有备用设置这些接口可以属于同一个复合设备中共存的不同功能。甚至几个独立的音频功能可以存在于同一个设备中。属于同一音频功能的接口被分组到音频接口集合中。如果设备包含多个独立的音频功能，则必须有多个音频接口集合，每个接口集合都提供对其相关音频功能的完全访问权限。

以复合设备为例，考虑配备内置立体声扬声器系统的 PC 监视器。这样的设备可以配置为具有一个处理配置和控制设备的监视器部分的接口 (HID 类），而其他两个接口的集合处理其音频方面其中之一，AudioControl 接口，是用来控制内部工作的 Function （音量控制等）。而另一个 AudioStreaming 接口，处理数据流量，发送到监视器的音频子系统。

AudioStreaming 接口可以配置为在单声道模式下工作（可选设置 x) 其中只有一个单声道数据流被发送到音频功能。接收输入终端可以将音频流复制到两个逻辑通道中，然后在两个扬声器上再现。从接口的角度来看，这样的设置除了 AudioControl 接口中的强制控制端点和可选中断端点之外，还需要音频流接口中的一个等时端点来接收单音频数据流。

同样的系统可以用来播放立体声音频。在这种情况下，必须选择立体声音频流接口（备用设置 y)。该接口还包含一个同步端点，该端点现在接收交错前左和前右通道采样的数据流。接收输入 Terminal 现在将流拆分为前左和前右逻辑通道。AudioControl 接口备用设置保持不变。如果上面的 AudioStreaming 接口是一个异步接收器，那么还需要一个额外的等时反馈端点。如前所述，音频功能位于设备类层次结构中的接口级别。以下各节描述了音频接口集合，其中包含单个 AudioControl 接口和可选 AudioStreaming 接口，以及用于音频功能控制和音频数据流传输的相关端点。

AudioControl Interface

为了控制特定音频函数的功能行为，主机可以操纵音频函数中的时钟实体、单位和终端。要使这些对象可访问，音频函数必须公开一个 AudioControl 接口。此接口可以包含以下端点

用于操纵时钟实体、单元和终端设置以及检索音频功能状态的控制端点。此端点是强制性的，默认端点 0 用于此目的
中断端点。此端点是可选的，但非常有用，应在除最简单的音频设备外的所有设备上实现，以便在音频功能的行为发生任何变化时，主机软件可以随时收到通知

AudioControl 接口是访问音频 Function 内部构件的单一入口点。所有与音频功能的时钟实体、单元或终端内的某些音频控件的操作有关的请求都必须指向音频功能的音频控件接口。同样，所有与音频函数内部相关的描述符都是特定于类的 AudioControl 接口描述符的一部分。音频功能的 AudioControl 接口只能支持单个备用设置。

Control Endpoint

音频接口类使用端点 0（默认管道）作为使用特定于类的请求控制音频功能的标准方式。这些请求总是指向组成音频 Function 的单元或终端之一。这些请求的格式和内容将在本文件中进一步详述。

Interrupt Endpoint

USB AudioControl 接口可支持可选中断端点，以通知主机音频功能内不同可寻址实体（时钟实体、端子、单元、接口和端点）上发生的动态变化。中断端点被整个音频接口集合用来向主机传递更改信息。它被认为是 AudioControl 接口的一部分，因为它是 Collection 的锚点接口。

AudioStreaming Interface

AudioStreaming 接口用于在主机和音频 Function 之间交换数字音频数据流。它们是可选的，一个音频 Function 可以有零个或多个与之关联的 AudioStreaming 接口，每个接口都可能携带不同性质和格式的数据。每个 AudioStreaming 接口最多只能有一个同步数据端点。这种构造保证了 Audiostreaming 接口和与端点相关的单个音频数据流之间的一对一关系。在某些情况下，同步数据端点伴随着一个相关的同步显式反馈端点，以实现同步。等时数据端点及其关联的反馈端点必须遵循 USB 规范第 9.6.6 节端点"中规定的端点编号方案。

AudioStreaming Interface 可以具有备用设置，可用于更改 Interface 和基础端点的某些特性。“ Alternate Settings”的典型用途是提供一种在 active Audiostreaming interface 上更改子帧大小/或通道数的方法。每当 Audiostreaming 接口需要同步数据端点时，它必须至少提供 0 带宽要求（未定义同步数据端点）的默认备用设置（备用设置 0) 和包含实际同步数据端点的附加备用设置。

音频流接口本质上是用来为主机软件（驱动程序）提供一个接入点来操作它所代表的物理接口的行为。因此，甚至外部连接到音频功能 (S/PDIF 接口， analog input 等）可以用音频流接口来表示，这样主机软件就可以控制这些连接的某些方面。这种类型的音频流接口没有关联的 USB 端点。相关的音频数据流不使用 USB 作为传输介质。

对于在任何 AudioStreaming 接口中定义的每个同步 OUT 或 IN 端点，必须在 audio 函 Function 中定义相应的输入或输出端子。为了让主机完全理解连接的性质和行为，它必须考虑与接口和端点相关的描述符以及与终端相关的描述符。

Isochronous Audio Data Stream Endpoint

通常，由等时音频数据端点处理的数据流不一定直接映射到音频功能中存在的逻辑通道。作为示例，考虑多个逻辑音频通道被压缩成单个数据流 (AC-3、WMA...) 的情况。这种数据流的格式可以完全不同于逻辑通道的原始格式（例如，640 Kbits/s AC-35.1 音频，而不是 6 通道 16 位 44.1 kHz 音频）。因此，为了正确地描述端点级的数据传输，逻辑信道的概念被音频数据流的概念所取代。包含 OUT 端点的 AudioStreaming 接口负责在音频数据流和嵌入式逻辑通道之间进行转换，然后将数据移交给输入终端。在许多情况下，这种转换过程涉及到某种形式的解码。同样，包含 IN 端点的 AudioStreaming 接口必须将输出终端的逻辑通道转换为音频数据流，通常使用某种形式的编码。如果解码或编码过程公开影响编码或解码的控件，则可以通过 AudioStreaming 接口访问这些控件。

无法将控制音频功能中存在的属性（如音量或静音）的请求发送到 Audiostreaming 接口中的端点。AudioStreaming 接口对音频数据流进行操作，并且不知道它最终服务的逻辑通道数。相反，这些请求必须通过 AudioControl 接口指向正确的音频功能单元或终端。如已经提到的，AudioStreaming 接口可以具有零个或一个等时音频数据端点。如果必须在主机和音频功能之间通信多个同步音频通道，则必须通过交织各个音频数据将它们聚集到一个物理音频通道簇中，然后将结果定向到单个端点。如果一个音频功能需要多个集群才能运行，则每个集群会定向到一个单独的 AudioStreaming 接口的端点，该接口属于同一个 Audiolnterface Collection （所有集群都服务于同一个音频功能）。

Isochronous Feedback Endpoint

对于自适应音频源端点和异步音频接收端点，需要显式同步机制来保持传输过程中的同步。有关同步的详细信息，请参见 USB 规范中的第 5 节”USB 数据流模型”。格式的具体信息，请参阅关于经过反馈管道的数据，请参见 USB 规范中的第 5.12.4.2 节”反馈"和第 9.6.6 节"端点”

Audio Data Format

用于通过 USB 传输音频数据的格式完全由特定于类的接口描述符的 bFormatType 和 bmFormats 字段中的代码决定。对于每个定义的格式类型，需要一个格式类型描述符来完整描述格式。有关已定义的格式类型以及相关数据格式和描述符的详细信息，请参见单独的文档 USB 音频数据格式该文档被认为是本规范的一部分。制造商必须充分记录特定于供应商的协议。

Clock Model

时钟实体提供了一种方法来准确地描述整个音频功能中采样时钟信号的使用和分布音频功能内部的采样频率只能通过与时钟源实体内部的采样频率控制直接交互来影响。采样频率控制范围属性为主机软件提供了必要的信息，以确定什么样的采样频率控制（以及因此相关联的时钟域）支持。改变采样频率的副作用可能是某些音频流接口可能需要切换到不同的备用设置，以支持新采样频率所需的带宽。此规范不允许 AudioStreaming 接口自行从一个备用设置切换到另一个备用设置，除非更改为备用设置零，这是空闲设置。相反，当音频功能检测到它不再支持 AudioStreaming 接口上的某个备用设置时，它必须在该接口上切换到备用设置零，并通过活动备用设置控制中断向主机软件报告更改。然后，主机可以通过 GET 有效的备用设置控制请求来查询接口的新的有效的备用设置，并进行适当的选择。注：若要将 AudioStreaming 接口中的备用设置数量保持在最低水平，建议不要为每个支持的采样频率提供单独的备用设置。相反，如果主机软件能够回收带宽即使是同步传输），提供一个活动备用设置可能就足够了。或者，只需几个活动备用设置（中等带宽，高带宽）就足以提供合理的带宽控制。音频流可以通过使用采样率转换器从一个时钟域桥接到另一个时钟域。

参考文献

《USB2.0 协议规范》
《UAC2 协议规范》