音频驱动程序架构

在 Fuchsia 中，驱动程序的架构方式有很多种，具体取决于所用驱动程序的数量、驱动程序之间的通信方式及其职责。音频驱动程序的职责由向驱动程序客户端公开的接口决定，客户端可以是其他驱动程序或使用驱动程序设施的应用用户。

定义

术语 定义
硬件编解码器 一种真实或虚拟设备，用于对数字/模拟信号进行编码/解码，以将其转换为模拟/数字信号，包括所有组合，例如数字到数字。 编解码器示例包括 DAC-Amplifiers 组合和 ADC 转换器。
控制器或引擎 系统中用于管理音频信号的硬件部分，例如 SOC 的音频子系统。
DAI 数字音频接口。音频硬件之间的接口，例如控制器和编解码器之间的 TDM 或 PDM 链接。
环形缓冲区 对用于数据传输的共享内存区域（在主内存中）的管理进行抽象；此共享内存区域由 VMO 对象提供。

音频接口

应用/客户端用户使用的音频驱动程序 API 是 音频复合接口。此 API 允许应用访问驱动程序公开的音频硬件功能。它允许驱动程序 公开各种类型硬件的功能，包括具有一个或多个 DAI 的 硬件编解码器、具有 环形缓冲区和 DAI 的控制器，以及 音频信号处理 API 允许的 任何处理元素组合。

音频硬件的常见拆分方式是，让音频引擎配置与音频硬件编解码器通信的 DAI。在这种拆分方式中，我们可以为音频引擎提供 一个驱动程序，为编解码器提供一个驱动程序。这两个驱动程序都可以使用 音频复合接口公开其相关功能。 编解码器驱动程序会公开一个或多个 DAI 互连接口，而音频引擎驱动程序会配置音频引擎硬件，包括连接到编解码器驱动程序的一个或多个 DAI。

这些驱动程序的客户端应配置所有驱动程序。此架构的示例用法是，对于具有两个不同编解码器（以物理方式连接到引擎）的系统，例如对 SoC 的音频子系统进行抽象。

                           +-----------------+
                +----------+     Client      +----------+
                |          +-----------------+          |
                |                   |                   |
          Composite API       Composite API      Composite API
                |                   |                   |
       +-----------------+ +-----------------+ +-----------------+
       | audio subsystem | |     Codec 1     | |     Codec 2     |
       +-----------------+ +-----------------+ +-----------------+

已废弃的接口

已废弃的接口包括：

  1. StreamConfig： 用于通过 audio_core 和 audio-driver-ctl捕获或呈现音频。前者是音频系统核心的第 1 版（提供软件混音、路由等），后者是用于测试和启动新平台的实用程序。

以前会使用 StreamConfig API 的驱动程序可以使用 音频复合接口（带一个环形缓冲区）来实现。

  1. 编解码器：用于抽象 具有一个 DAI 的硬件编解码器。以前会使用 Codec API 的驱动程序 可以使用 音频复合接口（带一个 DAI，不带环形缓冲区）来实现。

  2. DAI：用于抽象具有一个环形缓冲区和一个 DAI 的 SoC 硬件。以前会使用 DAI API 的驱动程序可以使用 音频复合接口（带一个 DAI 和一个环形缓冲区）来实现。

虚拟音频驱动程序

对于自动化测试和子系统开发，虚拟音频驱动程序在软件中模拟 音频硬件： * 新式 virtual-audio 驱动程序实现了 Composite API。 * 旧版 virtual-audio-legacy 驱动程序实现了已废弃的 StreamConfig、Dai 和 Codec API。