【Android Audio】从dumpsys media.audio_flinger诊断音频播放异常

1. 认识dumpsys media.audio_flinger

当你遇到Android设备播放音乐卡顿、通话无声或者游戏音效延迟时，作为开发者首先要想到的就是检查音频系统的运行状态。这时候dumpsys media.audio_flinger命令就像听诊器一样，能帮我们"听"到音频系统的内部状况。

这个命令会输出AudioFlinger服务的完整状态信息，AudioFlinger是Android音频系统的核心服务，负责所有音频流的混合和路由。我经常把它比作交通指挥中心——所有音频数据就像车辆，而AudioFlinger就是那个确保每辆车都能准时到达目的地的调度员。

执行方法很简单，在adb shell中直接输入：

bash复制adb shell dumpsys media.audio_flinger

或者如果需要保存到文件分析：

bash复制adb shell dumpsys media.audio_flinger > audio_flinger_dump.txt

输出的内容主要分为两大块：Output thread信息和Track列表。前者反映音频输出管道的整体状态，后者展示每个具体音频流的详细信息。就像去医院做体检，Output thread是全身检查报告，而Track列表是各个器官的专项检查。

2. 解读Output thread关键指标

2.1 基础配置信息

Output thread部分开头的几行信息就像设备的"身份证"：

text复制Output thread 0xf59a91c0, name AudioOut_7D, tid 3348, type 1 (DIRECT):
I/O handle: 125
Standby: no
Sample rate: 44100 Hz
HAL frame count: 2058
HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)

这里有几个需要特别关注的字段：

• Standby：显示"no"表示音频设备正在活跃状态，如果是"yes"则说明处于休眠，这时候如果应用在播放声音就可能有问题
• Sample rate：当前输出采样率，如果与应用设置的采样率不匹配会导致音调变化
• HAL format：音频硬件抽象层的数据格式，常见PCM_16_BIT(0x1)或PCM_FLOAT(0x5)

我曾经遇到过一个案例：某款设备的HAL强制使用48kHz采样率，而应用设置的是44.1kHz，导致音乐播放出现"唐老鸭"效应。通过这个字段很快定位到了问题。

2.2 设备与缓冲区状态

继续往下看的关键信息：

text复制Output devices: 0x400 (AUDIO_DEVICE_OUT_HDMI)
Normal frame count: 2058
Total writes: 658
Delayed writes: 0
Blocked in write: yes

这里藏着几个重要线索：

• Output devices：显示当前音频输出设备，比如0x400是HDMI，0x2是扬声器。如果设备选择错误会导致无声
• Normal frame count：输出缓冲区大小，单位是音频帧。值太小会导致频繁欠载(underrun)，太大会增加延迟
• Blocked in write：显示"yes"表示有写入阻塞，这是卡顿的直接证据

有个实际案例：某用户反馈蓝牙耳机听歌时不时卡顿，检查发现Normal frame count只有256，增大到1024后问题解决。这就是典型的缓冲区设置不当。

2.3 性能统计指标

这部分数据就像音频系统的"体检报告"：

text复制Timestamp stats: n=654 disc=0 cold=0 nRdy=0 err=5 rate=0.998184
Process time ms stats: ave=0.202382 std=0.656542 min=0.0575 max=46.0653
Hal write jitter ms stats: ave=-0.0991337 std=4.13872 min=-22.7821 max=24.3373

重点关注：

• Timestamp err：时间戳错误计数，非零值说明有同步问题
• Process time max：处理时间的最大值，突然飙高可能引发卡顿
• Hal write jitter：写入硬件的抖动情况，标准差过大说明系统负载高

我曾经用这些数据发现过一个CPU调度问题：当Process time的max值周期性飙高时，对应着系统后台服务的内存压缩操作，优化后音频卡顿问题消失。

3. 分析Track列表诊断具体问题

3.1 Track基本信息解读

Track列表展示了所有音频流的详细信息，格式如下：

text复制Type Id Active Client(pid/uid) Session Port Id S Flags Format Chn mask SRate ST Usg CT G db L dB R dB VS dB PortVol dB PortMuted Server FrmCnt FrmRdy F Underruns Flushed BitPerfect InternalMute Latency
63 yes 3128/10074 137 52 A 0x000 00000001 00000003 44100 3 1 3 0 0 0 0 0 false 000A5CE4 11025 8967 A 0 0 false false

几个关键列的解释：

• Active："yes"表示正在播放的track，如果应用在播放但显示"no"说明有问题
• Underruns：欠载计数，大于0说明数据供应不及时
• FrmRdy/FrmCnt：可用帧数/总帧数，比值过小会导致欠载
• Latency：当前延迟，单位毫秒

举个例子：如果游戏音效延迟明显，可以检查对应track的Latency值是否异常。我遇到过某款设备Latency经常超过200ms，最后发现是DSP固件的问题。

3.2 常见Track问题分析

根据多年经验，Track相关的问题主要有三类：

数据供应不足（Underruns）
表现为Underruns计数不断增加，可能原因：

• 应用写入速度不够（主线程阻塞）
• 缓冲区设置太小（FrmCnt值小）
• 系统负载过高（查看CPU使用率）

状态异常
观察S列的状态标识：

• 'A'：正常播放
• 'P'/'p'：暂停状态
• 'F'：已刷新
• 'S'：已停止

如果应用在播放但状态不是'A'，就需要检查应用代码的播放控制逻辑。

配置不匹配
常见的有：

• SRate（采样率）与设备支持不匹配
• Format（格式）不被硬件支持
• Chn mask（声道掩码）错误

曾经有个视频会议应用在特定设备上无声，最后发现是设置了24bit格式（0x3）但设备只支持16bit（0x1）。

4. 实战排查流程与技巧

4.1 系统性排查步骤

当收到音频问题报告时，我通常按以下流程排查：

1. 确认问题现象

   • 是否所有应用都有问题（判断是系统还是应用问题）
   • 问题是否特定于某些音频设备（如仅蓝牙有问题）

2. 获取audio_flinger dump

   bash复制adb shell dumpsys media.audio_flinger
   

   建议在问题发生时立即获取，因为有些状态是瞬时的

3. 检查Output thread

   • Standby状态是否符合预期
   • 输出设备是否正确
   • 是否有写入阻塞或延迟

4. 分析相关Track

   • 确认目标track是否Active
   • 检查Underruns和延迟
   • 验证格式、采样率等参数

5. 结合日志分析

   bash复制adb logcat -b all | grep -i audio
   

4.2 高级调试技巧

连续监控
使用watch命令定期获取状态：

bash复制adb shell watch -n 1 dumpsys media.audio_flinger

重点字段监控
如果怀疑是数据供应问题，可以特别关注：

• FrmRdy的变化趋势
• Underruns的增长速度
• Server指针的移动速度

压力测试
使用音频循环测试工具制造负载，观察系统表现：

bash复制adb shell tinymix # 查看混音器设置
adb shell tinyplay /sdcard/test.wav # 播放测试音频

性能分析
结合systrace查看音频线程调度：

bash复制python systrace.py audio -o trace.html

5. 典型问题案例解析

5.1 蓝牙音频卡顿问题

现象：使用蓝牙耳机听歌时每隔30秒左右会出现轻微卡顿。

分析过程：

1. 在卡顿时立即获取audio_flinger dump
2. 发现Output thread的Blocked in write为yes
3. 对应Track的Underruns计数在增加
4. 检查发现Normal frame count为768，相对较小
5. 查看mLocalLog发现大量"underrun"记录

解决方案：
修改audio_policy.conf，增大蓝牙A2DP的buffer大小：

text复制a2dp {
    sampling_rates 44100|48000
    channel_masks AUDIO_CHANNEL_OUT_STEREO
    formats AUDIO_FORMAT_PCM_16_BIT
    devices AUDIO_DEVICE_OUT_BLUETOOTH_A2DP
    flags AUDIO_OUTPUT_FLAG_PRIMARY
    frame_count 2048 # 从768调整到2048
}

5.2 游戏音效延迟问题

现象：某游戏在特定设备上音效延迟达500ms以上。

分析过程：

1. 游戏运行时获取audio_flinger状态
2. 发现游戏音效Track的Latency显示450.23ms
3. 该Track的Flags为0x41（DIRECT|HW_AV_SYNC）
4. 检查Output thread发现Standby延迟设置为300ms

解决方案：

1. 修改游戏音频配置，不使用DIRECT模式
2. 或者调整audio_policy的standby_timeout：

text复制audio_hw {
    standby_timeout 1000 # 从3000调整为1000ms
}

5.3 多应用同时播放无声

现象：当导航和音乐应用同时运行时，导航语音有时会无声。

分析过程：

1. 复现问题时获取audio_flinger dump
2. 发现音乐Track的Active为yes，而导航Track为no
3. 检查audio_policy配置发现导航的usage为AUDIO_USAGE_ASSISTANCE_NAVIGATION_GUIDANCE
4. 该usage的优先级低于音乐的AUDIO_USAGE_MEDIA

解决方案：
调整audio_policy的策略，提高导航语音的优先级：

xml复制<mixPort name="primary output" role="source" flags="AUDIO_OUTPUT_FLAG_PRIMARY">
    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
             samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
</mixPort>
<route type="mix" sink="Earpiece"
       sources="primary output,deep_buffer,compressed_offload,navigation"/>

6. 深入理解mLocalLog

audio_flinger dump的最后部分通常会包含mLocalLog输出，这是AudioFlinger内部的事件记录器，相当于系统的"黑匣子"。它的格式通常是：

text复制Local log:
10-26 23:43:33.747 AT::remove (0xf33840d0) S 57 no 657 137 24 S 0x600...
10-26 23:43:35.335 AT::add (0xf33840d0) S 57 no 657 137 24 A 0x200...

每行记录包含：

• 时间戳
• 操作类型（add/remove等）
• Track指针
• Track的简要状态

这些日志特别有助于诊断以下问题：

• Track的异常添加/移除
• 状态机的错误转换
• 资源竞争导致的死锁

我曾经通过分析mLocalLog发现过一个竞态条件：当快速切换播放状态时，会出现连续的add/remove操作，导致音频引擎崩溃。最终通过添加互斥锁解决了问题。

要获取更详细的日志，可以修改AudioFlinger的代码增加日志级别：

cpp复制#define LOG_NDEBUG 0
#define LOG_TAG "AudioFlinger"