模拟音频输入

延迟：0

可能有几个不同的模拟信号组件，例如内置麦克风的前置放大器。在这种情况下，这些模拟信号组件可以被视为“零延迟”，因为它们的真实延迟通常低于 1 毫秒。

模数转换器（ADC）

延迟：1 毫秒

音频芯片以既定的时间间隔测量传入的音频流，并将每个测量值转换为一个数字。这个既定的时间间隔称为采样率，以 Hz 为单位。48000 Hz 是 Android 和 iOS 设备上大多数音频芯片的原生采样率，这意味着音频流每秒被采样 48000 次。

由于 ADC 实现通常在内部包含一个过采样滤波器，因此这个过程将产生接近1毫秒的延迟。

经过ADC的处理模拟音频变成数字信号。数字音频无法在系统中逐个传输，而是以块的形式，称为“缓冲区”或“周期”。

内存总线

延迟：1-6 毫秒

音频芯片有几个任务。它处理 ADC 和 DAC，在多个输入和输出之间切换或混合、调整音量等。它还将离散数字音频样本“分组”到缓冲区中，并负责处理这些缓冲区数据传输到操作系统。

音频芯片通过 USB、PCI、Firewire 等总线连接到 CPU。每条总线都有自己的传输延迟，具体取决于其内部缓冲区大小和缓冲区数量。此处的延迟范围通常从 1 毫秒（设备内部的音频芯片）到 6 毫秒（性能一般的USB总线）。

音频驱动程序

延迟：一个或多个周期

音频驱动程序把音频芯片产生的音频传输到缓冲区当中，缓冲区起到了平滑数据传输速率、避免抖动的作用，因此自然会增加一些延迟。

Android底层基于Linux实现，因此大多数 Android 设备使用了Linux 音频驱动系统ALSA（高级 Linux 声音架构）。ALSA会有序的处理缓冲区数据：

• 音频以特定周期从缓冲区中被消费。

• 缓冲区的大小是“周期大小”的倍数。

例如：

• 周期大小 = 480  sample。

• 周期数 = 2。

• 缓冲区的大小为 480x2 = 960 个样本。

• 一个周期（480 个样本）大小的音频写到缓冲区，而音频堆栈读取/处理另一个周期的缓冲区（480 个样本），形成双缓冲机制。

• 延迟 = 1 个周期，480 个样本。它在 48000 Hz 时等于 10 ms。

常见的周期数是 2，但有些系统可能会更高。

音频硬件抽象层(HAL)

延迟：0（最佳情况）

HAL是Android 媒体服务器和 Linux 音频驱动程序之间的中间件。HAL由OEM厂商负责实现，这些厂商可以自由实现HAL逻辑。媒体服务器加载 HAL时会要求使用可选的首选参数（例如采样率、缓冲区大小或音频效果）创建输入或输出流。

注意：HAL是否根据参数执行我们无法知道，所以媒体服务器必须“适应”HAL。

典型的 HAL 实现是 tinyALSA，它用于与 ALSA 音频驱动程序通信。一些厂商会在这里实现一些重要的功能，并且是闭源的。

糟糕的HAL会给音频链路增加不必要的延迟和 CPU 负载。一个好的HAL 实现不应增加任何延迟。

Audio Flinger

延迟：1 段时间（最佳情况）

Android 媒体服务器由两个服务组成：

• AudioPolicy 服务处理音频会话和权限，例如开启或关闭麦克风。和iOS的音频会话处理类似。

• AudioFlinger 服务处理数字音频。

Audio Flinger 创建一个 RecordThread，它充当应用程序和音频驱动程序之间的中间人。基本工作流程如下：

• 使用Android HAL从驱动程序的缓冲区获取下一个音频输入。

• 如果应用程序请求的采样率与原始采样率不同，则对缓冲区重新采样。

• 如果应用程序请求的缓冲区大小与本机周期大小不同，则执行额外的缓冲。

Audio Flinger 有一个“快速混音器”的实现（如果厂商有实现的话）。如果应用程序使用硬件原生支持的采样率的缓冲区大小，则系统将会跳过重采样和无必要的混合处理。

RecordThread 使用“push”的工作方式，与音频驱动程序没有任何严格同步，因为它需要预测合适应该运行，这会额外增加延迟。低延迟系统应该使用“pull”方法，音频驱动程序驱动整个音频链路的运行，而不是预测什么时候应该从缓冲区读取数据。很显然，Android系统早期设计并没有考虑到对低延迟的支持。

Binder

延迟：0

Android进程间通讯的重要组件，用于在 Audio Flinger 和应用程序之间传输音频数据。

AudioRecord

延迟：0+ samples

这里处于应用程序的进程中。AudioRecord 实现了音频输入客户端。

AudioRecord线程定期从 Audio Flinger 获取新缓冲区，使用 Audio Flinger 中描述的“推送”原理。如果开发人员将其设置为仅使用一个缓冲区，则不会增加音频路径的延迟。

User Application

延迟：超过 1 个周期，通常接近 2 个（最佳情况）

最后，音频输入的目的地，即用户应用程序。

由于输入和输出线程不同，用户应用程序必须在线程之间实现环形缓冲区。它的大小最小为 2 个周期（1 个用于音频输入，1 个用于音频输出），但编写得不好的应用程序通常使用更多的缓冲区以解决CPU瓶颈。

AudioTrack

延迟：0+ samples

AudioTrack用于应用程序的音频输出。它运行一个线程定期将下一个音频缓冲区发送到 Audio Flinger。在 Android 4.4.4 之后，AudioTrack不会增加额外延迟，因为它可以设置为只使用一个缓冲区。

Binder

延迟：0

与音频输入相同。

Audio Flinger

延迟：1 段时间（最佳情况）

创建一个 PlaybackThread，它与音频输入中描述的 RecordThread 相反。

音频硬件抽象层(HAL)

延迟：0（最佳情况）

与音频输入相同。

音频驱动程序

延迟：一个或多个周期

音频驱动程序中的音频输出与音频输入的工作方式相同，并且也使用环形缓冲区。

内存总线

延迟：1-6 毫秒

与音频输入总线传输类似，此处的延迟范围通常为 1 ms 到 6 ms。

模数转换器（ADC）

延迟：1 毫秒

与 ADC 相反，这里会将数字信号转为模拟信号。根据经验假设 DAC 的延迟为 1 ms。

模拟音频输出

延迟：0