15、音频输出通路：PlaybackThread详解、DirectOutput与Offload路径、HDMI/蓝牙等特殊输出路径
各位同学，今天我们来聊聊音频输出通路。说白了，就是音频数据从AudioFlinger出来之后，到底是怎么跑到扬声器、耳机或者蓝牙设备上去的。这部分内容，我个人觉得是理解Android音频框架的关键。你想想看，上层应用调用了AudioTrack的write()，数据就丢下去了，但底层是怎么流转的？这里面门道可不少。
15.1 PlaybackThread：音频输出的核心调度器
PlaybackThread，这个名字起得很直白——播放线程。它是AudioFlinger里负责管理音频输出流的基类。我刚开始看源码的时候，觉得这玩意儿就是个线程，后来才发现，它其实是一个精心设计的调度框架。
每个PlaybackThread对应一个音频输出设备（比如内置扬声器、耳机、蓝牙A2DP等）。它内部维护了一个MixerThread（混音线程）或者DirectOutputThread（直通输出线程），具体用哪个，取决于上层传下来的音频格式和策略。
嗯，这里要注意：PlaybackThread不是直接操作硬件的。它通过一个AudioStreamOut的接口来跟HAL层打交道。这个接口，说白了就是HAL层暴露给上层的一个“写音频数据”的通道。
核心职责：
- 管理音频数据缓冲区（BufferQueue）
- 调度多个Track的混音（如果是MixerThread）
- 处理音量、声道映射、采样率转换
- 与HAL层交互，驱动音频输出
我曾经在一个项目中遇到过一个问题：播放音乐时偶尔出现“啪”的一声爆音。查了很久，最后发现是PlaybackThread的缓冲区大小配置不当，导致底层DMA传输时出现了underrun。嗯，从那以后，我对缓冲区大小的计算就格外小心了。
15.2 DirectOutput与Offload路径：绕过混音，直通硬件
常规的音频播放，数据会经过MixerThread混音。但有些场景下，我们不需要混音，比如播放一个高码率的FLAC文件，或者播放一个已经编码好的MP3/AAC流。这时候，DirectOutput和Offload路径就派上用场了。
15.2.1 DirectOutput路径
DirectOutput，直译就是“直接输出”。它跳过了MixerThread的混音步骤，直接把单个Track的数据送到HAL层。这样做的好处是：延迟更低，而且能保持原始音频格式（比如24bit/192kHz）。
触发条件是什么？我总结了一下：
- 只有一个活跃的Track
- Track的格式与输出设备支持的格式匹配（比如都是PCM）
- 没有要求混音（比如没有其他音效叠加）
说白了，就是“你一个人独占输出通道，别跟别人抢”。
避坑指南： 我曾经在调试车载系统时发现，某些车机在播放导航语音时，音乐会被强制暂停。原因就是导航语音使用了DirectOutput，而音乐Track被系统认为“不兼容”，直接踢掉了。解决方案是让导航语音走混音路径，或者使用低延迟的Offload路径。
15.2.2 Offload路径
Offload路径，是Android 5.0引入的一个大杀器。它把音频解码的工作“卸载”到硬件DSP或者Codec上。什么意思呢？比如你播放一个MP3文件，正常情况下，CPU要解码成PCM，然后混音，再送出去。Offload路径下，CPU直接把压缩的MP3数据包发给HAL层，由硬件解码并输出。
这样做的好处很明显：
- CPU负载大幅降低（省电）
- 延迟更低（硬件直接处理）
- 支持高码率格式（比如Dolby Atmos）
但缺点也有：
- 不能混音（Offload路径只支持单个Track）
- 音效处理受限（硬件DSP不支持所有音效）
- 兼容性问题（不同芯片的Offload实现差异很大）
我记得有一次，某款手机播放QQ音乐时，开启音效后声音就断了。查下来发现，QQ音乐走了Offload路径，而音效插件需要PCM数据，两者冲突了。最后解决方案是：检测到音效开启时，强制走MixerThread路径。
15.3 特殊输出路径：HDMI与蓝牙
除了常规的扬声器和耳机，Android还支持HDMI和蓝牙等特殊输出设备。这些设备的路径，跟普通的PlaybackThread不太一样。
15.3.1 HDMI输出路径
HDMI输出，说白了就是把音频数据打包成HDMI格式，通过HDMI线缆送到电视或功放。Android里，HDMI音频走的是AudioFlinger::PlaybackThread::HDMI路径。
关键点：
- HDMI支持多声道（5.1、7.1）
- 支持高采样率（192kHz）
- 支持压缩格式（如Dolby Digital、DTS）
嗯，这里有个坑：HDMI的EDID信息。EDID是显示器/电视告诉播放设备“我能支持什么格式”的数据。如果EDID信息不完整，或者解析错误，音频输出可能会降级到立体声，甚至无声。
警告： 我曾经在调试某款投影仪时，发现HDMI音频输出只有左声道有声音。查了三天，最后发现是HDMI线的第19针（热插拔检测）接触不良，导致EDID读取失败。换了一根线就好了。所以，硬件问题有时候比软件更坑。
15.3.2 蓝牙输出路径
蓝牙音频，现在越来越普及了。Android里，蓝牙音频走的是A2DP（Advanced Audio Distribution Profile）协议。AudioFlinger会创建一个专门的Bluetooth A2DP PlaybackThread。
蓝牙路径的特点：
- 数据需要编码（SBC、AAC、LDAC、aptX等）
- 延迟较高（通常100-200ms）
- 支持音效（但受限于蓝牙带宽）
我个人觉得，蓝牙音频最大的挑战是延迟。你想想看，手机播放视频，声音比画面慢了半拍，那体验多糟糕。Android从Pie开始引入了AAudio和MMAP机制，就是为了降低蓝牙音频的延迟。
还有一个常见问题：蓝牙设备断开重连时，音频通路需要重新建立。如果处理不好，就会出现“有声音但没输出”的情况。我建议在开发时，监听ACTION_ACL_CONNECTED和ACTION_ACL_DISCONNECTED广播，及时刷新音频路由。
15.4 知识体系总览
为了让大家更直观地理解这些路径的关系，我画了一张图：
从这张图可以看出来，不同的输出路径最终都汇聚到HAL层，但中间的调度逻辑完全不同。MixerThread负责混音，DirectOutputThread负责直通，OffloadThread负责硬件解码。你选择哪条路，取决于你的应用场景和硬件能力。
15.5 总结
好了，这一章的内容就到这里。我们聊了PlaybackThread的核心作用，也深入分析了DirectOutput和Offload路径的区别，还顺带讲了HDMI和蓝牙的特殊处理。说白了，音频输出通路就是一条数据管道，但这条管道的设计，直接决定了音频的延迟、功耗和音质。
我个人觉得，理解这些路径的关键，在于搞清楚“数据在哪里被处理”。是在CPU里混音？还是直接丢给硬件？不同的选择，带来不同的结果。你在实际开发中，可以根据需求灵活选择。
小提示： 如果你在调试音频输出问题时，可以用dumpsys media.audio_flinger命令查看当前活跃的PlaybackThread和Track信息。这个命令会列出所有输出线程的状态，包括缓冲区大小、采样率、声道数等。我曾经靠这个命令，定位过一个蓝牙音频断断续续的问题——原来是缓冲区太小，导致频繁underrun。
公众号:蓝海资料掘金营，微信deep3321