17、多声道音频路由：多声道设备识别、声道映射策略、环绕声路由配置
多声道音频路由，说白了就是让系统知道「你有几个喇叭，每个喇叭该放什么声音」。
我刚开始接触这块时，以为就是简单的左声道右声道。直到第一次调试5.1声道的Soundbar，才发现事情远没那么简单。你想想看，一个设备可能物理上有7个喇叭，但系统只认2个声道，或者反过来——系统以为有8个声道，但设备只有2个喇叭。这种错配，就是多声道路由要解决的核心问题。
17.1 多声道设备的识别机制
Android系统怎么知道一个音频设备支持几个声道？
嗯，关键在 AudioProfile 和 AudioDeviceInfo 这两个类。
// 获取设备支持的声道数
AudioDeviceInfo device = audioManager.getDevices(AudioManager.GET_DEVICES_OUTPUTS).get(0);
int[] channelCounts = device.getChannelCounts();
for (int count : channelCounts) {
Log.d("AudioRoute", "支持声道数: " + count);
}我在项目中遇到过一个问题：某款USB声卡明明支持7.1声道，但系统只识别出2声道。查了半天，发现是声卡的USB描述符里没有正确声明多声道能力。说白了，硬件说了谎，系统只能按最低标准来。
设备识别流程
- HAL层上报设备能力（声道数、采样率、格式）
- AudioFlinger解析并创建对应的混音器
- 路由策略根据设备能力决定是否允许多声道输出
17.2 声道映射策略
声道映射，就是把音频流的声道布局，转换成设备实际的物理声道布局。
举个例子：你有一个5.1声道的电影，但你的设备只有立体声喇叭。这时候系统必须把5个声道+低音炮，映射到左、右两个声道上。怎么映射？这就是策略问题了。
我个人习惯的做法：先判断源布局和目标布局是否一致。一致就直接透传，不一致才做downmix或upmix。
17.2.1 常见的声道布局
| 布局名称 | 声道数 | 声道掩码 |
|---|---|---|
| 立体声 | 2 | CHANNEL_OUT_STEREO |
| 5.1 | 6 | CHANNEL_OUT_5POINT1 |
| 7.1 | 8 | CHANNEL_OUT_7POINT1 |
| Atmos | 动态 | CHANNEL_OUT_ATMOS |
17.2.2 Downmix（降混）策略
多声道转立体声，最常用的就是ITU-R BS.775标准。简单说就是：
- 左声道 = 左前 + 0.707 * 左环绕 + 0.707 * 中置
- 右声道 = 右前 + 0.707 * 右环绕 + 0.707 * 中置
- 低音炮按比例分配到左右
我曾经踩过一个坑：某款电视在播放5.1内容时，中置声道的声音完全丢失了。查代码发现，downmix矩阵里中置的系数写成了0。嗯，这种低级错误，一旦上线就是事故。
17.2.3 Upmix（升混）策略
立体声转多声道，这个更讲究。你不能简单地把左声道复制到左前和左环绕，那样听起来像回声。
我建议的做法是：
- 中置：提取左右声道的共模成分（人声、乐器）
- 环绕：提取差模成分（环境音、混响）
- 低音炮：提取低频成分（< 120Hz）
注意：Upmix算法没有标准答案。不同厂商的算法差异很大。如果你在做产品，一定要做主观听音测试。我见过一个方案，upmix后环绕声像「水烧开了」一样咕噜咕噜响，那就是算法参数没调好。
17.3 环绕声路由配置
环绕声路由，核心是解决「什么内容走什么设备」的问题。
举个例子：你插了HDMI音响，又连了蓝牙耳机。系统应该把5.1声道的电影走HDMI，把微信语音走蓝牙耳机。这就是路由策略要做的事。
17.3.1 策略优先级
Android的环绕声路由策略，我总结为三层：
- 应用层策略：App可以指定输出设备（比如视频播放器强制走HDMI）
- 系统层策略：根据音频属性（Usage、ContentType）选择设备
- HAL层策略：硬件自己决定是否支持多声道
这三层是叠加的。应用层优先级最高，但最终能不能生效，还得看HAL层支不支持。
17.3.2 动态路由切换
用户可能在播放过程中插拔设备。这时候系统要做什么？
- 检测到新设备插入 → 判断是否支持多声道
- 如果支持 → 重新建立音频通路
- 如果不支持 → 保持现有路由，或者做downmix
我记得有一次调试，用户插上HDMI后，声音反而没了。原因是HDMI设备报告支持多声道，但实际只支持2声道PCM。系统以为可以传5.1，结果HDMI接收端解码失败。最后我们在路由策略里加了一层「能力验证」——先发一段测试音，确认设备真的能解码，再切换路由。
17.4 核心知识体系
下面这张图，是我自己整理的多声道路由核心逻辑。你看一遍，基本就能理解整个流程了。
17.5 实战建议
如果你正在做多声道路由的开发，我有几点建议：
- 先确认硬件能力：不要相信设备上报的声道数，用测试音验证一下。我吃过这个亏。
- 做好降级策略：多声道路由失败时，要能优雅地降级到立体声。用户宁可听立体声，也不要没声音。
- 日志要详细：多声道路由的bug很难复现。我习惯在每个决策点都打日志，包括：设备能力、源布局、目标布局、映射矩阵、最终路由结果。
一句话总结：多声道路由的核心就三件事——识别设备能力、决定映射策略、执行路由切换。把这三点理清楚，剩下的就是填代码了。
公众号:蓝海资料掘金营，微信deep3321