Android 音频无声排查：从 Dolby/MS12 配置到 HAL、ALSA 与 HDMI

这篇写什么？

盒子 / Soundbar 上「画面有、声音没有」是最高频的音频故障之一。原因可能在：

• 软件配置（芯片能力 vs Dolby/DTS 库 vs MS12 vs audio_policy / media_codecs）
• 运行时状态（被 mute、没建 AudioTrack、underrun）
• 数据通路（HAL / MS12 / ALSA 某一环空了）
• 驱动或 HDMI / 电视（tinymix、tinyplay、HDMI Lock）

本文把现场常用的排查步骤整理成一条可复用的路径，方便按图索骥。框架分层背景可先看：Android 音频框架总览。

一句话：

先确认现象与复现条件
  → 查配置是否「芯片 / 库 / policy / codecs / MS12」自洽
  → 查是否 mute、AudioTrack 是否活跃
  → aml_tool 分段 dump，定位第一段坏掉的数据
  → tinymix / tinyplay / HDMI Lock 区分 HAL、驱动、电视

〇、复现时先问清这几句

抓 log 之前，先把边界钉死，避免「全链路乱 dump」：

抓 log 最小集合：

1. user 版本：bugreport + AV log；无声时执行
   adb shell dumpsys media.audio_flinger > /sdcard/flinger.log
2. userdebug / debug 版本：再加 aml_tool 分段抓音频数据（见下文）
3. 附上：复现步骤、概率、电视型号、按键音 / YouTube 是否正常

一、配置层：芯片、Dolby/DTS 库、MS12、Policy、Codecs

很多「必现无声」其实不是运行时偶发，而是 镜像配置自相矛盾。DTS 与 Dolby 的匹配逻辑类似。

1.1 芯片能力 vs Dolby / DTS 库

Dolby 解码库与 透传库往往同名，靠体积区分（经验值）：

典型错误组合（都会无声或特定格式无声）：

补充测试经验：接 不支持 Dolby 的电视，本地播 Dolby 码流，也可能无声——要区分是「盒子库配错」还是「电视能力不够」。

现场快速判断（以 Amlogic / Android S 常见接口为例）：

# 芯片侧（部分版本有权限限制）
cat /sys/class/amaudio/dolby_enable

# AudioManager getParameters（厂测更稳妥）
# dolby_ms12_enable / dolby_decode_enable / dts_decode_enable

厂测建议：不支持 Dolby 却发现解码库 / 误带 MS12，应直接报错拦截，而不是等到客户现场才无声。

1.2 MS12 是否加载成功、efuse 是否烧对

带 MS12 的项目：

1. 库是否加载
   • 可关注 dolby_lib_type：常见约定 2 = MS12 成功，1 = 不带 MS12 库（以你们平台打印为准）
   • 常见路径：
     • Q：/odm/lib/libdolbyms12.so 或 /vendor/lib/libdolbyms12.so
     • R 及以后常见：/odm/lib/ms12/libdolbyms12.so
2. odm 侧解码产物
   • 检查 odm/etc/ms12 下配置 / 库是否正确，能否解码落到 odm/lib/ms12
   • 解不出时，优先怀疑 未烧 audio efuse（按平台烧录文档重烧）
3. 软件根本没编进库
   • odm/etc/ms12 下也没有 libdolbyms12.so → 查项目 .mk 宏是否打开 MS12 编译

规则再强调一次：不支持 Dolby 的芯片不要编 MS12；带 MS12 必须保证 efuse + 库加载都正确。

1.3 audio_policy_configuration.xml 是否匹配

Policy XML 决定上层能声明哪些格式、走哪些 output。配错会直接把「设备不支持的格式」送到 HAL。

编译侧经验：

• Android 12：常用宏控制 copy 哪份 XML 到 /vendor/etc
• Android 14：多由脚本生成 XML 再拷贝（相对 S 的配置方式有变化）

1.4 media_codecs.xml（DTS 同理）

不支持 Dolby / MS12 的项目，不要编进 Dolby 解码组件。否则部分 APK 会主动走解码组件，反而无声。

芯片支持且带解码库 → 才配置 AC3/EAC3（及对应 DDP xml）；不支持则整条链路都不要「假装支持」。

1.5 创建 AudioTrack 失败：格式与电视能力不匹配

若 log 显示创建 AudioTrack 失败，且提示格式 / 声道不匹配：

1. adb shell dumpsys media.audio_policy 看 policy 是否声明了该格式
2. 查 HDMI 后端能力，例如：
   cat /sys/class/amhdmitx/amhdmitx0/aud_cap
3. 对比「上层要建的格式」vs「电视 EDID 能力」

典型案例：上层建 AC3 7.1，电视只报 AC3 6ch，创建失败无声；若电视支持 MAT 8ch，对带 MS12 的项目往往应视为可向下兼容 AC3/EAC3 7.1 Atmos——此时要查 HAL 是否正确把 MAT 能力纳入判断。
同时复查：是否误用了「不支持 Dolby 项目」的 policy XML。

二、运行时：是不是根本没出声？

2.1 流是否被 mute

优先排除「被别的应用静音」：

• bugreport / AudioService 的 volume changes 日志（谁、何时、ADJUST_MUTE）
  例如 Katniss 等助手静音 STREAM_MUSIC 的案例并不少见
• logcat 搜 mute
• 无声时用 debug 工具看 system / 其它流音量；或用 adb / 小工具读当前音量

相关内部案例线索：待机唤醒后偶发无声、被应用 mute 等（如 AML-1379 一类）。

2.2 AudioTrack / AudioFlinger 是否活跃

无声时：

adb shell dumpsys media.audio_flinger

关注 Output thread：

• Standby: yes → 该通路关闭
• Standby: no（false） → 通路打开

若播放中 dump 找不到任何 Standby=no 的活跃输出，说明 没有活跃 AudioTrack，数据没进 HAL。

也可在 debug 版本打开 AudioTrack write 相关打印（如主分支通过 setprop 打开 stagefright / omx debug），确认 write 是否在跑；同时看 HAL out_write 是否被调用。

2.3 underrun：有轨但写空了

log 中若出现类似：

ms12 system input underrun ... write=0

说明 没有数据写到 MS12 输入，表现为无声。要回到 App / OMX / 解码链路查「谁没喂数」。

三、数据层：aml_tool 分段 dump（最关键）

配置与 mute / Track 都正常时，用 aml_tool（或平台等价 debug 工具）在无声瞬间抓各阶段 PCM/RAW：

对比原则： 找到「上一阶段有、下一阶段空 / 异常」的第一环，再去对 HAL 接口调用栈。
若 进 HAL 与写 ALSA 都正常，问题多半在 驱动或 HDMI TX（需平台侧配合：内核 / HDMITX log）。

辅助验证：

• AV 口 / SPDIF / 蓝牙若同源，可判断「是否只是 HDMI 口无声」
• 同时确认 AudioTrack write 与 HAL out_write 是否都有调用

四、通路层：tinymix、端口与 mute

当 dump 各阶段数据看起来正常，查混音与端口。

4.1 关注字段（名称因平台略有差异）

经验规则（以常见 Soundbar / 盒子实现为例）：

核对：audiohal 打开的 ALSA 端口 是否与 tinymix 里 HDMI 所选输入一致；不一致会导致「HAL 有数、口上无声」。
若 mute：可按控件编号手动打开，例如 tinymix 18 0（编号以机型 tinymix 列表为准）。

电视侧能力再次确认：

cat /sys/class/amhdmitx/amhdmitx0/aud_cap

五、驱动：tinyplay 一刀切开 HAL vs Kernel

若 HAL / dump 都正常仍无声：

1. 推一段 WAV 到 /sdcard
2. cat /proc/asound/pcm 确认 card / device
3. 直接播：

tinyplay /sdcard/48k16bit2ch.wav -D 0 -d 4 -c 2 -r 48000 -b 16

六、HDMI：Lock 区分「盒子」还是「电视」

怀疑 HDMI 时：

1. 按平台文档做 HDMI Lock，固定链路后再换电视试
2. 换电视有声 → 更偏向原电视 EDID / 能力 / 兼容
3. 仍无声 → 偏盒子 HDMITX / 驱动；抓 HDMITX 与内核 log（平台 common 无声文档）

同时可对照 SPDIF / AV / 蓝牙是否有声，缩小「仅 HDMI」还是「全局无声」。

七、推荐排查顺序（实战 Checklist）

按这个顺序走，效率最高：

1. 现象：按键音 / YouTube / 音量恢复 / 概率 / 电视型号
2. 配置：芯片能力 ↔ Dolby/DTS 解码或透传 ↔ MS12 有无 ↔ efuse ↔ policy XML ↔ media_codecs
3. mute：AudioService volume change、logcat mute、应用是否静音
4. Track：dumpsys media.audio_flinger 是否有 Standby=no；创建失败则对 policy + aud_cap
5. 数据：aml_tool 对比 system_in → MS12 → ALSA；搜 underrun
6. 混音：tinymix 端口、格式、mute 是否与 HAL 打开设备一致
7. 驱动：tinyplay
8. HDMI：Lock + 换电视 + HDMITX/内核 log

配置自洽？ ──否──→ 改库 / XML / codecs / efuse / 宏
    │是
运行时 mute / 无 Track / underrun？ ──是──→ 查 App / 焦点 / 解码喂数
    │否
分段 dump 哪一环先空？ ──定位──→ HAL 调用栈
    │ALSA 仍正常
tinymix / tinyplay / HDMI Lock ──→ 驱动 or 电视

八、小结

无声不是单一 bug，而是 能力声明（XML/库/MS12）、运行时状态（mute/Track）、数据是否贯通（dump）、物理口与电视（tinymix/HDMI） 四层叠加。

最容易踩的坑仍是这三类：

1. 不支持 Dolby 却用了解码库 / MS12 / 带 Dolby 的 policy 与 codecs
2. 带 MS12 却没烧对 audio efuse，或 deep_buffer 依赖 MS12 却未生效
3. HAL/ALSA 有数，但 tinymix 口选错、被 mute，或电视能力不匹配导致建轨失败

把「配置自洽」和「分段 dump」做扎实，大部分无声问题都能在一天内收敛到具体一层。

相关阅读：

• Android 音视频同步排查
• Android 音量问题排查
• Android 音频框架总览
• Android 音量设置流程
• ALSA period / 缓冲
• 语音模块入门