在 Fuchsia 中，驱动程序的架构方式有很多种，具体取决于所用驱动程序的数量、它们的通信方式以及它们的职责。音频驱动程序的职责由暴露给驱动程序客户端的接口决定，客户端可以是其他驱动程序或使用驱动程序设施的应用程序用户。
定义
| 术语 | 定义 |
|---|---|
| 硬件编解码器 | 一种真实或虚拟设备，可将信号从数字/模拟编码/解码为模拟/数字，包括所有组合，例如数字到数字。 编解码器示例包括 DAC-放大器组合和 ADC 转换器。 |
| 控制器或引擎 | 系统中用于管理音频信号的硬件部分，例如 SOC 的音频子系统。 |
| DAI | 数字音频接口。音频硬件之间的接口，例如控制器和编解码器之间的 TDM 或 PDM 链路。 |
| 环形缓冲区 | 用于数据传输的共享内存区域（在主内存中）的管理抽象；此共享内存区域由 VMO 对象提供。 |
| 数据包流 | 通过离散数据包传输来抽象基于数据包的音频流式传输（例如，对于 AAC 和 SBC 等编码音频格式）。 |
音频接口
音频驱动程序的应用/客户端用户要使用的 API 是 Audio Composite Interface。此 API 允许应用访问驱动程序公开的音频硬件功能。它允许驱动程序公开各种类型硬件的功能，包括具有一个或多个 DAI 的硬件编解码器、具有环形缓冲区、数据包流和 DAI 的控制器，以及 Audio Signal Processing API 允许的任何处理元素组合。
音频硬件中常见的一种拆分方式是，让音频引擎配置与音频硬件编解码器通信的 DAI。在这种拆分方式中，我们可以为音频引擎和编解码器分别配备一个驱动程序。这两个驱动程序都可以使用音频复合接口来公开其相关功能。编解码器驱动程序将公开一个或多个 DAI 互连接口，而音频引擎驱动程序将配置音频引擎硬件，包括连接到编解码器驱动程序或多个驱动程序的 DAI。
这些驱动程序的客户端应配置所有驱动程序。此架构的一种使用示例，适用于两个不同编解码器实际连接到引擎的系统，例如抽象化 SoC 的音频子系统。
+-----------------+
+----------+ Client +----------+
| +-----------------+ |
| | |
Composite API Composite API Composite API
| | |
+-----------------+ +-----------------+ +-----------------+
| audio subsystem | | Codec 1 | | Codec 2 |
+-----------------+ +-----------------+ +-----------------+
已弃用的接口
已弃用的接口包括：
- StreamConfig：用于通过 audio_core 和 audio-driver-ctl 捕获或渲染音频。前者是音频系统核心的第 1 版（提供软件混音、路由等），后者是用于测试和启动新平台的实用程序。
之前使用 StreamConfig API 的驱动程序可以使用带有一个环形缓冲区的 Audio Composite 来实现。
编解码器：用于通过一个 DAI 抽象化硬件编解码器。以前使用编解码器 API 的驱动程序可以使用 Audio Composite（一个 DAI，无环形缓冲区）来实现。
DAI：用于通过一个环形缓冲区和一个 DAI 来抽象化 SoC 硬件。以前使用 DAI API 的驱动程序可以使用音频复合（包含一个 DAI 和一个环形缓冲区）来实现。
虚拟音频驱动程序
对于自动化测试和子系统开发，虚拟音频驱动程序可在软件中模拟音频硬件：
* 新式 virtual-audio 驱动程序实现了 Composite API。
* 旧版 virtual-audio-legacy 驱动程序实现了已弃用的 StreamConfig、Dai 和 Codec API。