4. 音频数据流路径：从APP到硬件的完整链路
好，咱们今天聊点实在的。音频数据从APP里播放出来，到最终从扬声器出声，这中间到底经历了什么？我当年刚接触AOSP音频系统时，也被这条链路搞得晕头转向。说白了，这就是一条数据管道，每一段都有它自己的职责。
4.1 整体链路概览
先画个轮廓。音频数据从应用层到硬件，大致要经过这么几站：
- APP层：调用AudioTrack或AudioRecord接口
- Framework层：AudioFlinger负责混音和路由
- HAL层：硬件抽象层，与驱动打交道
- Kernel层：ALSA驱动，最终操作硬件寄存器
你想想看，一个音频数据包从Java层一路跑到硬件，中间要经历多少次拷贝和转换？我数过，至少3到4次。嗯，这里要注意，每一次拷贝都是性能损耗。
4.2 Buffer分配与管理
Buffer管理是整个音频系统的命脉。我个人习惯把Buffer分为三个层级：
| 层级 | 位置 | 大小 | 生命周期 |
|---|---|---|---|
| 应用层Buffer | APP进程空间 | 由APP指定，通常4KB-64KB | APP创建，APP销毁 |
| 共享内存Buffer | AudioFlinger管理的共享内存 | 由AudioFlinger分配，通常8KB-128KB | AudioFlinger管理 |
| HAL层Buffer | HAL进程空间 | 由HAL分配，通常与硬件周期对齐 | HAL管理 |
我在项目中遇到过一个问题：某个APP申请了64KB的Buffer，但HAL层只支持16KB的周期。结果就是数据被截断，声音出现爆音。后来怎么解决的？让APP的Buffer大小必须是HAL周期大小的整数倍。
核心原则：Buffer大小必须对齐。不对齐，就会出问题。这是血的教训。
4.3 数据格式转换
数据格式转换是音频链路中最容易被忽视的环节。你以为APP传过来的是PCM数据就能直接送给DAC？太天真了。
常见的格式转换包括：
- 位宽转换：16位转24位，或32位转16位
- 采样率转换：44.1kHz转48kHz，或48kHz转96kHz
- 通道转换：立体声转单声道，或5.1声道转立体声
- 字节序转换：小端转大端，或反之
我曾经接手过一个项目，播放音乐时声音总是变调。查了两天，最后发现是采样率转换的系数算错了。嗯，这种低级错误，一旦出现，排查起来特别痛苦。
我的建议：在HAL层实现一个数据格式检查函数，每次数据进来先校验格式是否匹配。不匹配就报错，别偷偷转换。偷偷转换的结果就是声音不对，你还不知道哪里出了问题。
4.4 数据流的具体路径
咱们以播放为例，走一遍完整流程：
- APP调用write()：数据进入应用层Buffer
- AudioFlinger接收：通过共享内存拿到数据，放入混音器
- 混音处理：多个音频流混合成一个输出流
- 格式转换：如果需要，进行采样率、位宽等转换
- 写入HAL：调用HAL的write接口，数据进入HAL Buffer
- 驱动处理：HAL调用ALSA驱动，数据写入DMA Buffer
- 硬件播放：DMA将数据送入DAC，最终从扬声器出声
你可能会问，为什么要有这么多层？直接让APP操作硬件不行吗？不行。Android是多任务系统，多个APP可能同时播放音频。AudioFlinger的作用就是做混音和策略管理。没有它，你听歌时来个通知，声音就打架了。
4.5 避坑指南
我曾经踩过的坑：
- 共享内存没有同步，导致数据读写冲突。解决方案：使用环形Buffer加读写指针。
- HAL层Buffer太小，导致频繁中断，CPU占用飙升。解决方案：根据硬件周期计算最优Buffer大小。
- 格式转换时没有考虑对齐，导致内存访问异常。解决方案：使用memcpy前先检查地址对齐。
说实话，音频数据流路径这块，理解了Buffer怎么流转，基本就掌握了80%。剩下的20%是各种边界情况和异常处理。我建议你在移植时，先在HAL层打日志，把每一步的Buffer地址、大小、格式都打印出来。这样出了问题，一眼就能看出是哪一步不对。
好了，这一章就到这里。下一章咱们聊聊AudioFlinger的混音策略，那才是真正体现功力的地方。