3. 音频数据通路（Audio Path）：Playback通路、Capture通路与混音策略
好，咱们今天聊点实在的。音频数据通路，说白了就是声音在座舱里怎么走。你想想看，从手机导航说了一句“前方300米右转”，到喇叭里真正响起来，中间经过了哪些环节？这就是我们要拆解的东西。
我个人习惯把音频通路分成两大块：Playback（播放）和Capture（采集）。前者是声音出去，后者是声音进来。中间还有个关键的“调度中心”——混音与路由管理。咱们一个一个说。
3.1 Playback通路：媒体、导航、TTS
Playback通路，就是声音从应用层一路走到喇叭的过程。在座舱里，最常见的三个场景是：媒体播放、导航提示、以及TTS（语音合成）。
你可能会问：这三个有啥区别？嗯，区别大了去了。媒体是娱乐，导航是提示，TTS是交互。它们的优先级、延迟要求、音质需求都不一样。
3.1.1 媒体播放通路
媒体播放，比如听歌、看视频。这条通路的特点是：音质优先。我建议走独立的硬件通道，避免被其他声音干扰。
典型的通路是这样的：
应用层（音乐App） → AudioFlinger/AudioTrack → 音频HAL → DSP解码 → DAC → 功放 → 喇叭这里有个坑。我在项目中遇到过，有些方案把媒体和导航混在同一个DSP通道里，结果导航一响，音乐就被压缩得很难听。嗯，这就是路由没做好。
关键点：媒体通路建议使用48kHz采样率，16bit或24bit位深。如果支持无损音频，可以考虑96kHz。
3.1.2 导航通路
导航提示音，比如“前方500米有测速”。这条通路的特点是：实时性高。你想想看，如果导航延迟了2秒，车都开过了路口才提示，那还有什么用？
导航通路一般走低延迟路径：
导航引擎 → 音频策略管理器 → 混音器 → DSP（低延迟通道） → DAC → 喇叭我个人习惯把导航音放在前台播放，并且给它一个较高的优先级。这样即使后台在放音乐，导航也能“插队”出来。
小技巧：导航音建议使用单声道，8kHz或16kHz采样率就够了。别用立体声，浪费带宽，还增加延迟。
3.1.3 TTS通路
TTS，就是语音合成。比如小爱同学说“好的，已为您打开空调”。这条通路和导航类似，但更强调自然度和可打断性。
TTS的通路设计：
TTS引擎 → 音频策略管理器 → 混音器 → DSP（带语音增强） → DAC → 喇叭我曾经踩过一个坑：TTS播放时，如果用户突然说话，系统没有及时打断TTS，结果就是人机对话“打架”。后来我加了一个语音打断机制，当检测到用户说话时，立刻暂停TTS播放。
注意：TTS的增益要单独控制。别和媒体音量混在一起调，否则用户把媒体音量调小了，TTS也听不见了。
3.2 Capture通路：麦克风阵列与语音唤醒
说完了声音出去，咱们聊聊声音进来。Capture通路，就是麦克风采集声音，送到算法处理，最后给到应用层。
座舱里最常见的两个场景是：麦克风阵列采集（用于通话、语音识别）和语音唤醒（比如“你好，小迪”）。
3.2.1 麦克风阵列通路
现在的座舱，少则2个麦克风，多则6个甚至8个。麦克风阵列的作用是：波束成形和降噪。
典型的通路：
麦克风阵列 → 模拟前端（AFE） → ADC → DSP（波束成形+降噪） → 音频HAL → 应用层这里有个关键点：同步采集。所有麦克风必须同步采样，否则波束成形的效果会大打折扣。我在项目中遇到过，因为时钟不同步，导致波束方向偏移了30度，语音识别率直接掉到60%。
建议：麦克风阵列使用PDM接口，通过同一时钟源驱动。采样率统一为16kHz或48kHz。
3.2.2 语音唤醒通路
语音唤醒，就是系统在待机状态下，一直监听麦克风，等待唤醒词。这条通路的特点是：低功耗和始终在线。
唤醒通路的设计：
麦克风 → 低功耗音频DSP（始终监听） → 唤醒引擎 → 唤醒系统 → 启动主DSP我个人习惯把唤醒算法放在独立的低功耗DSP上跑。这样主芯片可以休眠，功耗能降到毫瓦级。你想想看，如果唤醒也要主芯片跑，那车停一晚上电瓶就亏了。
避坑指南：我曾经把唤醒阈值设得太低，结果路噪都能触发唤醒。后来加了双麦克风差分和风噪检测，误唤醒率才降下来。
3.3 混音策略与路由管理
好，现在Playback和Capture都讲完了。但问题来了：多个声音同时播放怎么办？比如导航在说“前方右转”，音乐在放《孤勇者》，TTS在说“已为您打开空调”。这三个声音怎么混在一起？谁先谁后？
这就是混音策略和路由管理要解决的问题。
3.3.1 混音策略
混音，就是把多个音频流合并成一路。常见的策略有三种：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 叠加混音 | 所有声音直接相加，音量不变 | 媒体+导航（导航音量独立控制） |
| 衰减混音 | 高优先级声音播放时，低优先级声音降低音量 | 导航提示时，音乐音量降低 |
| 独占混音 | 高优先级声音播放时，低优先级声音暂停 | 紧急报警音（如碰撞预警） |
我个人习惯用衰减混音。导航提示时，音乐音量降20%-30%，但不要完全静音。这样既不影响导航，也不让用户觉得音乐断了。
优先级排序（从高到低）： 安全报警音 > 电话通话 > 导航提示 > TTS > 媒体音乐
3.3.2 路由管理
路由管理，就是决定声音从哪个通道走。比如：导航音走前排喇叭，还是全车喇叭？电话通话走蓝牙耳机，还是车载麦克风？
路由管理的核心是策略引擎。它根据当前场景，动态切换音频路由。
举个例子：
场景：用户正在听音乐，突然来了电话
策略引擎动作：
1. 暂停音乐播放（或降低音量）
2. 将电话音频路由到全车喇叭
3. 将车载麦克风路由到电话上行
4. 挂断后，恢复音乐播放我在项目中遇到过一个问题：电话挂断后，音乐没有恢复。后来发现是路由状态机没有正确回退。嗯，这里要注意，路由管理一定要有状态恢复机制。
注意：路由切换时，要避免“噗”的爆音。我建议在切换前先做静音渐变，比如50ms内逐渐切换，人耳基本听不出来。
3.4 总结一下
好，咱们把这一章的内容串一下：
- Playback通路：媒体走音质优先通道，导航走低延迟通道，TTS走可打断通道。
- Capture通路：麦克风阵列要同步采集，语音唤醒要低功耗独立DSP。
- 混音策略：用衰减混音，优先级排序要合理。
- 路由管理：动态切换，注意状态恢复和防爆音。
说白了，音频通路设计就是一场“交通调度”。声音就是车，通路就是路，混音和路由就是红绿灯和交警。调度得好，座舱里一片和谐；调度不好，用户就想砸车。
下一章，咱们聊聊音频策略引擎的具体实现。到时候我会拿高通SA8155的代码来拆解，看看实际项目里是怎么做的。