1、音频系统概述：车载音频系统架构、Android Automotive音频栈、核心术语
各位同学好，我是你们的老朋友。今天咱们正式开始聊车载音频系统。说实话，这个领域我摸爬滚打了快十年，踩过的坑比走过的路还多。但正是这些经历，让我觉得有必要把里面的门道好好梳理一遍。
音频系统在车里有多重要？你想想看，导航提示、电话通话、音乐播放、语音助手，甚至倒车雷达的滴滴声，全得靠它。要是音频出问题，那体验感直接归零。我见过不少项目，硬件选型花了大价钱，结果软件通路没设计好，最后用户一上车就骂娘。
好，咱们直接进入正题。
1.1 车载音频系统架构
车载音频系统，说白了就是一套从音源到扬声器的完整链路。但跟手机不一样，车里的环境复杂得多。
先看整体架构，我习惯把它分成三层：
- 应用层：各种音源APP，比如音乐播放器、导航、电话、语音助手。它们只管产生音频数据。
- 框架层：Android Automotive的音频服务，负责策略决策、路由管理、混音。这是咱们课程的核心。
- 硬件层：DSP、功放、扬声器阵列、麦克风。物理世界的东西，但软件得把它们管好。
这里有个关键点：车载音频不是简单的“播放-输出”。它要处理多路并发、优先级抢占、不同声学空间（比如主驾、副驾、后排）的独立控制。我在项目中遇到过，导航播报时音乐要自动降低音量，但后排乘客想继续嗨——这种需求，策略设计不好就会出乱子。
核心要点：车载音频架构的难点不在于单个模块有多复杂，而在于如何协调好各路音频的“话语权”。
1.2 Android Automotive音频栈
Android Automotive的音频栈，是在标准Android基础上做了大量定制。为什么？因为手机不需要管那么多扬声器，也不需要处理紧急呼叫优先于一切这种场景。
整个栈从下往上，我习惯这么看：
- HAL层：硬件抽象层，直接跟DSP、Codec打交道。这里定义了音频设备、端口、路由。
- AudioFlinger：音频引擎，负责混音、播放、录制。它是真正的“干活”的模块。
- AudioPolicyService：策略决策者，决定哪个音频该走哪条路、该不该被其他音频打断。
- AudioManager：应用层接口，APP通过它来控制音量、焦点、模式。
嗯，这里要注意。车载场景下，AudioPolicyService的重要性被放大了无数倍。因为车里可能有十几个音频输出设备，每个设备对应不同的声区。我建议你在学习时，把精力重点放在策略层——底层驱动再牛，策略不对也是白搭。
个人经验：调试车载音频时，我习惯先看AudioPolicy的配置文件。很多时候问题出在策略配置上，而不是代码bug。我曾经花了一周时间追一个“导航声音忽大忽小”的问题，最后发现是策略里音量曲线配错了。
1.3 核心术语详解
咱们把三个最核心的术语掰开揉碎了讲。这些概念你搞不懂，后面寸步难行。
1.3.1 AudioPolicy
AudioPolicy，直译是“音频策略”。它干的事很简单：决定“谁的声音，从哪出来，音量多大，要不要被其他声音打断”。
举个例子：你正在听音乐，突然来了电话。AudioPolicy会判断：电话优先级高于音乐，所以音乐要暂停或降低音量，电话音频走车载蓝牙或扬声器。这个决策过程，就是AudioPolicy的职责。
在Android Automotive里，AudioPolicy通过一个XML配置文件来定义规则。我记得第一次看到这个文件时，密密麻麻的节点和属性，头都大了。但后来发现，只要理解了“设备”、“路由”、“策略”这三个概念，就豁然开朗。
<!-- 一个简化的AudioPolicy配置片段 -->
<audioPolicyConfiguration>
<globalConfiguration speaker_drc_enabled="false"/>
<modules>
<module name="primary" halVersion="3.0">
<attachedDevices>
<item>Speaker</item>
<item>BuiltInMic</item>
</attachedDevices>
<route type="mix">
<source name="music" />
<sink name="Speaker" />
</route>
</module>
</modules>
</audioPolicyConfiguration>
避坑指南：我曾经在某个项目里，因为漏配了一个路由规则，导致导航音频死活不出声。排查了两天才发现，原来导航的音频源没有映射到正确的输出设备上。所以，配置文件的每一行都要仔细核对。
1.3.2 AudioFlinger
AudioFlinger是音频栈的“发动机”。它负责把多个音频流混音成一路，然后送给HAL层输出。说白了，它就是那个“把所有人的声音合成一首歌”的调音师。
它的核心工作流程：
- 接收来自不同APP的音频数据（Track）
- 按照策略进行混音（Mixer）
- 通过HAL接口写入硬件（Output）
这里有个技术细节：AudioFlinger支持多种混音模式。比如，对于导航提示这种短暂的声音，可以用快速混音；对于音乐播放，可以用高质量混音。我在项目中遇到过，混音参数没调好，导致导航播报时音乐有“噗噗”的爆音。后来调整了混音缓冲区大小，问题就解决了。
关键点：AudioFlinger的性能直接影响音频延迟和音质。车载场景下，延迟要求比手机更严格——导航提示晚100毫秒，你可能就错过路口了。
1.3.3 HAL（硬件抽象层）
HAL是连接Android框架和硬件驱动的桥梁。它定义了一组标准接口，让上层不用关心底层用的是哪家DSP、哪个Codec。
在车载音频里，HAL层通常要处理：
- 多声道输出（5.1、7.1甚至更多）
- 回声消除（AEC）
- 噪声抑制（NS）
- 动态范围控制（DRC）
我建议你重点关注HAL的“设备枚举”和“路由切换”这两个接口。因为车载音频的硬件拓扑比手机复杂得多，一个HAL实现得好不好，直接决定了上层策略能不能落地。
// HAL中定义音频设备的示例
struct audio_device {
char *name; // 设备名称，如"Speaker"
audio_devices_t type; // 设备类型，如AUDIO_DEVICE_OUT_SPEAKER
uint32_t channels; // 声道数
uint32_t sample_rate; // 采样率
};
个人建议：调试HAL层时，一定要先确认硬件设备枚举是否正确。我见过太多案例，上层策略配得完美无缺，结果HAL层根本没识别到某个扬声器，导致所有努力白费。所以，第一步永远是“看看设备列表对不对”。
1.4 三者关系总结
AudioPolicy、AudioFlinger、HAL，这三者的关系，我用一个比喻来解释：
- AudioPolicy 是交通指挥官，决定哪辆车（音频流）走哪条路（设备）
- AudioFlinger 是高速公路收费站，把所有车流合并成一条主干道（混音）
- HAL 是路面本身，直接跟轮胎（硬件）接触
三者缺一不可。策略错了，音频走错路；混音出问题，声音变味；HAL没配好，直接没声音。你想想看，任何一个环节出问题，用户体验就是灾难。
好了，这一章的内容就到这里。音频系统的概述是基础中的基础，后面的章节我们会深入到每个模块的源码和实战调优。记住，搞车载音频，策略思维比代码能力更重要——这是我用无数个加班夜换来的教训。