MTK平台的音频无声问题在Android项目开发里属于那种“看起来不难、查起来头大”的典型case。我自己在MTK方案上调音频也不是一次两次了从展锐切到MTK平台那阵子光是audio_path这块就踩了不少坑。网上关于音频框架的文章很多但大多数是基于高通或者标准AOSP来讲的真到了MTK平台配置路径、设备节点、Audio HAL的行为都有差异拿通用思路去套往往查半天找不到根因。这篇就专门针对MTK平台Audio无声问题把排查思路和音频路径配置的完整链路梳理一遍希望能帮正在被这个问题折磨的兄弟省点时间。这个内容适合谁看主要是做Android系统开发、BSP开发、或者负责音频功能移植和定制的工程师。哪怕你是刚接触MTK平台不久的新手只要按顺序走一遍排查流程大概率能自己定位到问题层面而不是一头扎进代码里瞎翻。文章不会只扔结论每一步都会解释“为什么这么做”因为排查问题最怕的就是只会执行命令、不懂原理换一台机器换个场景又抓瞎。1. 音频无声问题的整体判断思路1.1 无声问题不是一种问题先做“三分法”我见过不少同事一上来就抓logcat、翻代码折腾半天还在原地打转。其实音频无声这类问题第一步不是查代码而是把问题归类。以我的经验MTK平台上的无声问题基本可以分成三类全场景无声、局部场景无声、偶发/特定操作后无声。这三种的排查方向和重点完全不同。全场景无声意思是开机后播放音乐、提示音、通话全部没声音这种问题大概率出在底层codec初始化失败、I2S/TDM配置错误、Speaker/Receiver的PA供电没起来甚至kernel里audio相关的dts配置就有问题。而局部场景无声比如只有通话无声、只有录音无声、只有蓝牙无声那往往和音频路由策略AudioPolicy有关或者和某个具体设备节点如mic、earpiece的通路配置有关。偶发无声则要重点看时序是不是播放与录音同时发生时出现的是不是休眠唤醒后无声这类问题多与电源管理、audio HAL的状态机有关。先分清类型能省掉大量无用功。我自己的习惯是拿到bug的第一步就反问三件事是所有场景都听不到声音还是只有某个场景是第一次开机就没有还是用着用着才没有复位或重启后会不会恢复这三个问题基本能帮你把问题范围缩小到某个模块。1.2 排查前必须准备好的几个工具和手段MTK平台 Audio 无声问题排查不是纯靠看代码就能解决的必须有工具辅助而且要在拿到问题设备的第一时间就把现场数据采集全。最常用的就是adb。adb shell dumpsys audio看音频策略和当前活跃的音频设备adb shell dumpsys media.audio_flinger看AudioFlinger内部每个播放流的状态和采样信息adb logcat -s AudioFlinger AudioPolicyManager AudioMTKStreamManager看上层音频框架日志。MTK平台还有一个特有的调试入口就是/proc/driver/audio和Audio HAL层的debugfs节点等会会细讲。除了抓log还必须准备好tinyalsa工具集。MTK的Android系统里通常自带了tinyplay、tinycap、tinymix在/system/bin下一般可以直接用。这三件套是用来看底层音频设备状态和直接打通路的。如果系统里没有可以自己push一个静态编译的tinyalsa工具进去。另外/sys/kernel/debug/mtk_audio或类似节点下会有详细的audio driver状态信息里面能看到每个audio device的开关状态和时钟情况。提示调试过程中尽量不要断电或频繁重启优先用adb bugreport抓一整份系统信息。很多音频无声问题在重启之后log就丢了现场状态没了排查难度翻倍。2. MTK平台音频路径和配置文件解析2.1 MTK与高通平台在音频架构上的关键差异很多人习惯于高通平台的思路硬件路径由audio_policy_configuration.xml定义音频路由由AudioPolicyManager根据strategy选择device然后走Audio HAL的open_output_stream和start_output_stream控制。这套思路在MTK平台上大体成立但不完全一样因为MTK平台的Audio HAL和AudioPolicy之间的耦合方式有自身特点。MTK早期平台比如Android 5~7那会儿用的是AudioMTKStreamManager来统一管理输入输出流并直接对接Audio HAL层。而这个Manager的行为又和mtk_audio_policy.conf中的配置紧密相关。到了Android 8以后MTK逐渐向AOSP的Audio HAL结构靠拢但依然保留了一些私有扩展比如AudioALSADeviceParser、AudioMTKStreamIn/Out这些类以及audio_hal层对Audio_AfeAudio Front End的直接操作。所以排查MTK音频问题时不能完全照搬高通那套“查XML路由表”的方法。MTK平台除了要看audio_policy_configuration.xml还要看一个容易被忽略的文件filesystem_config.xml或audio_device.xml里对底层alsa device的映射关系。更重要的是MTK的AudioPolicyManager在启动路由前会通过AudioHAL去open对应的物理设备如Speaker、Headphone而物理设备是否探测到、是否被去抖逻辑屏蔽会直接影响最终的路由结果。说直白点高通平台如果某个场景无声通常是route表中的某个device配置错MTK平台如果无声有可能是device探测成功但HAL内部并没有把它连到对应的DAIDigital Audio Interface上。这种软硬结合的耦合点正是MTK平台最容易出问题的地方。2.2 音频路径相关配置文件都藏在哪儿MTK平台的音频路径配置从上层到下层至少涉及四类文件排查的时候要按层级来找。第一层是audio_policy_configuration.xml通常在device/mediatek/board/或vendor/mediatek/proprietary/packages/modules/Audio/下。这个文件定义了设备、策略、混音器配置是AudioPolicyManager读取的主文件。第二层是audio_device.xml和audio_policy_engine_config.xmlMTK用来做设备映射和策略引擎配置。第三层是Audio HAL相关的配置文件比如audio_hal_config.xml这里定义了音频流类型、采样率、通道数等HAL参数。第四层是kernel侧的dtsmediatek系列平台的cust_audio.dtsi和codec相关的配置以及mtk-soc-machine、mtk-afe-pcm的设备树节点直接对应硬件I2S/TDM到codec的物理连接。实际排查中第四层dts经常被忽略但它出问题时的表现和上层策略配置错误几乎一模一样。比如Speaker无声如果你只盯着audio_policy_configuration.xml看改来改去发现没效果最后发现是dts里codec的pa-supply节点没配GPIO根本没拉高那真是欲哭无泪。我建议接到MTK无声问题后先把这几类文件按目录结构列出来拍照留档然后逐层检查。尤其要注意MTK不同芯片平台比如MT6765、MT6853、MT8788之间的配置模板差异不小不要拿一个平台的配置直接去套另一个平台。2.3 从上层到底层的音频链路到底是怎么串起来的要排查MTK平台的无声问题必须对整个链路有一个清晰的认识。这条链路由四个环节组成。最上层是应用和AudioFlinger。应用通过AudioTrack写入PCM数据AudioFlinger中的MixerThread负责混音和重采样然后把数据写入Audio HAL的output stream。第二层是AudioPolicyManager。它根据当前的音频策略比如媒体、通话、导航和场景来选择路由到哪个输出设备并触发对应的设备切换。第三层是MTK的Audio HAL在这层会完成从逻辑设备到物理pcm节点的转换比如输出到Speaker时会打开Audio_DL1这类DAI经过Audio AFEAudio Front End送给kernel。最后一层是kernel的ALSA框架mtk-afe-pcm等驱动负责把AFE和外部Codec如MT6359系列Codec连接起来最终把数字信号转成模拟信号输出到功放和喇叭。这条链路里任何一环断裂都会导致无声。我的排查习惯是自上而下先从dumpsys确认上层输出是否正常再确认HAL层是否切换到了正确设备最后用tinyplay直接从底层打通路验证物理链路是否OK。这样二分法推进不用一上来就硬啃代码。3. 实操排查流程从现象到根因3.1 第一步用dumpsys看清“上层以为自己在干什么”拿到无声问题我一般会先执行几个dumpsys命令确认系统上层的状态是否正常。这一步的核心目标是搞清楚系统知道自己正在播放吗它选择的路由设备是哪个音量是否为0或极低AudioFlinger是否在正常接收PCM数据先看音频策略和路由状态adb shell dumpsys audio | grep -E state|device|mode|strategy重点关注Output devices和Input devices的输出。如果能看到Speaker之类的设备被激活说明AudioPolicyManager已经完成了路由选择。如果这里显示的device不对或者显示None那问题大概率出在AudioPolicyManager的决策过程。接着查看Media/Music流是否真的在跑adb shell dumpsys media.audio_flinger | grep -E active|track|sample rate|normal|output这条命令能反映出AudioFlinger中是否存在活跃的播放线程Thread。比如看到T 0x... Active说明播放线程正在运行说明数据流有在上层流动。如果连active thread都没有那可能是应用端就没启动播放或者AudioFlinger挂了。如果active thread存在但下面依然无声那问题就到了HAL和底层。另外dumpsys audio里还有一个容易被忽略的信息音量曲线。MTK平台上如果某个stream的volume从-3.0 dB直接被衰减到了-70 dB甚至silent也会产生无声的假象。检查一下每个stream的当前音量状态确认不是软件层面的静音策略把声音掐掉了。3.2 第二步通过logcat确认路由切换过程dumpsys看到的是状态快照但问题是“什么时候选择错了路”还得靠log。检查音频相关的log时不要打开所有tag去刷屏否则有效信息被淹没。我这里按优先级整理了需要重点看的几个tagAudioPolicyManager或新平台的AudioPolicyEngine负责路由选择遇到startOutput、getOutputForAttr、setOutputDevices这类日志就是它在切换设备。如果看到路由时对应的device不是期望值说明策略配置有问题。AudioMTKStreamManager是MTK Audio HAL层的核心管理类输出流切换时它会打印打开的硬件端口。AudioMTKStreamOut/AudioMTKStreamIn能看到这条流最终映射到哪个硬件pcm设备。audio_hw_primary或对应HAL名字负责实际和kernel通信如果打开pcm节点失败这里会有明显错误。抓log时有一个值得注意的动作先logcat -c清空旧日志然后开始播放声音操作捕抓完整过程。比如复现“播放音乐无声”操作流程应该是清log—打开音乐—等待3~5秒—暂停—停止。这样出来的log时间线非常清晰每个阶段的音频行为都能对上。注意MTK新平台的log tag会有些变化比如老一点的Android 9上tag就叫AudioMTKStreamManager到了Android 12/13上可能会变成AudioALSAManager或MTKAudioPolicyManager。系统源码头文件里搜一下LOG_TAG就能确认别完全照搬我给的tag名。3.3 第三步用tinyplay和tinymix打通底层链路验证到了HAL层还看不出问题就必须下沉到kernel链路验证。最简单的做法是用tinyplay直接播放一段wav文件绕开AudioFlinger和AudioPolicyManager直接让HAL/Kernel去播放。先把一段44100Hz、双声道、16bit的wav文件push到设备adb push test.wav /data/local/tmp/ adb shell cd /data/local/tmp tinyplay test.wav -D 0 -d 0这里-D 0表示pcm card 0-d 0表示pcm device 0。MTK平台不同的输出通道对应不同的pcm device编号。比如常见的Audio_DL1可能在-d 0而Audio_DL2可能在-d 1。如果你不确定映射关系可以看一下/proc/asound/pcmcat /proc/asound/pcm这个文件会列出所有可用的pcm节点比如00-00: MTK PCM : : playback 1 : capture 1 00-01: MTK PCM : : playback 1 : capture 0如果tinyplay播放officer有声音说明从DMA、AFE、codec到喇叭的底层模拟信号通路是好的问题在上层路由或策略。如果tinyplay播放也无声那就要结合tinymix检查底层硬件状态。tinymix是用来查看和操作codec/SoC内部mixer控件的工具。先导出当前所有的mixer控件状态tinymix /data/local/tmp/mixer_state.txt播放时导出一份播放无声时再导出一份对比差异重点看以下几点PA的switch控件是否打开比如MTK_SPEAKER_EN、Speak_GAIN等、codec的input/output是否连接到了正确的通路、音量类控件比如PGA、DAC增益是否为0或极低。3.4 第四步确认Kernel侧的ALSA和Codec状态如果tinymix里的通路看着是通的但tinyplay依然无声问题基本就锁定在kernel侧了。会看/proc/asound/card0/codec#0是一个技能点。这个文件会列出当前codec里面所有widget的状态。比如MTK常见的MT6359/MT6358 codec在正常播放时Left Speaker Mixer和Right Speaker Mixer相关widget应该处于ON状态而且DAC到HPOUT或SPKOUT的通路连接标识应该是connected。如果这些widget是off或不连接说明通路的控制逻辑有问题。有一个排查重点是确认codec的时钟状态。MTK平台的音频时钟由mtk-afe-clock和mtk_audio驱动管理。查看/sys/kernel/debug/mtk_audio/audio_mem和时钟状态节点有些平台在/sys/kernel/debug/audio/clock下确认Audio PLL比如APLL1/APLL2是否处于锁定状态。如果PLL没lock即使通路配对了也不会有声音而且这种情况在外接耳机时最容易出现。有一回我排查一个项目Speaker始终无声tinyplay也不行最后发现居然是因为kernel侧codec的clock divider配置不对采样率越高偏得越离谱人耳听着像完全没声音。所以clock这块是很值得优先检查的点。4. 无声音问题的典型案例与问题排查技巧4.1 案例一开机后所有声音都没有但dumpsys显示正常这是一个非常典型的MTK平台问题。现象是开机后没有任何声音但dumpsys audio一切正常播放时也能看到active thread在跑说明上层软件完全在工作。这种场景下我一般直接跳到底层验证。操作手法是先用tinyplay直接播放。如果tinyplay没声音再去看mixer_state确认Speaker的enable控件是不是没开。我遇到过一次原因出在MTK的AudioHAL打开输出流时需要根据AudioPolicy下发的device类型去打开对应的硬件通路但因为AudioPolicy配置中Speaker对应的device name与HAL中定义的字符串不一致导致HAL虽然收到了“切换到Speaker”的命令却匹配不到对应的底层通路。代码里既不会报错上层状态又一切正常无声就这么“安静”地发生了。排查这种问题的方法很简单也高效打开AudioHAL里suspendAudioDevice、openOutputOnSameAudioDevice这类函数打印出实际请求挂断和打开的device类型字符串跟底层alsa device map做对比两类字符串只要大小写差一个字母或多了个空格通路就切不过去。4.2 案例二只有通话无声媒体播放正常通话无声在MTK平台上多数跟audio policy中的电话模式in_call配置相关。媒体播放正常说明底层DAC、codec、喇叭通路都是完好的。问题往往出在路由策略上通话场景应该切到voice_call或telephony设备但有可能当前配置里通话路由被定向到了一个不存在的物理设备上或者MIC和earpiece的路径配置不对。在MTK平台上通话模式比较特殊它不单纯是走正常的AudioFlinger通道还涉及modem侧的语音通道。媒体正常、通话无声排查顺序建议是先看通话时dumpsys audio的mode是否进入MODE_IN_CALL然后确认当前的输出device是不是EARPIECE或SPEAKER根据免提状态再看看调制解调器侧是否把语音送到了codec的对应端口。如果这一切正确可以试着用tone播放器播放DTMF音来猜一个想法如果通话中对方听不到你播放DTMF时对面能听到说明modem到codec的上行语音链路是通的问题在mic侧如果播放DTMF都听不到那就要怀疑下行语音链路或者通话路由没接通。4.3 案例三蓝牙耳机无声但机内喇叭正常蓝牙音频在MTK平台上也是容易出无声的一个环节。普通排查思路是检查蓝牙A2DP是否成功连接、协议栈状态是否正常。但MTK平台上有一个细节蓝牙音频在MTK方案里并非完全走标准A2DP硬编解码路径而是经常走软编解码所以一旦蓝牙耳机无声必须把logcat -s bt_audio_a2dp_hw和logcat -s AudioA2dp两个tag都抓出来看。如果log显示A2DP已经播放但无声并且tinyplay等本地播放都正常那么问题大概率出在A2DP的encode链路。MTK平台的A2DP软编解码有一个特点它的编解码器由Audio HAL内部管理如果SBC/AAC的参数协商不对有可能出现“数据在跑但编码后数据无法播放”的诡异问题。这类问题我建议先换一种编码方式测试。在开发者选项中切换一下“蓝牙音频编解码器”比如从AAC切到SBC如果切换后声音恢复正常基本可以判定是特定编码器参数适配问题要么升级蓝牙固件要么在代码里强制修正该编码器的采样率或比特率。如果切换编码器后问题依旧那再考虑蓝牙协议栈层的路由问题。4.4 常见问题速查表一条一条对照着查为了节省大家的时间我可以把MTK平台音频无声问题整理成一张速查表。这张表不能保证100%覆盖所有场景但实际项目里80%的无声问题都逃不出这几条主线。现象优先怀疑点快速验证方法大概率修复方向全场景无声Codec初始化失败、PA供电异常tinymix查看PA开关cat /proc/asound/card0/codec#0检查widget检查dts中pa-supply节点与GPIO配置媒体无声、提示音正常多媒体音频路由未映射到输出设备dumpsys audio查看media策略的devicelogcat查AutoRoute检查audio_policy_configuration.xml中media对应的device通话无声in_call路由指向无效设备dumpsys audio确认MODE_IN_CALL下device修正通话路由配置核对modem音频通道录音无声MIC通路blocked、或MIC bias未开启tinymix查看MIC Bias控件tinycap抓录音检查mic dts配置确认micbias电压休眠唤醒后无声音频时钟PLL在suspend时被关闭未恢复查看/sys/kernel/debug/mtk_audio下时钟状态修改runtime pm与audio时钟关断逻辑外接耳机无声Headset type识别错误dts中耳机检测引脚电平、cat /sys/class/switch/h2w/state校准耳机的检测电阻配置蓝牙无声A2DP编解码协商失败开发者选项切换蓝牙编码器修改蓝牙编码配置代码偶发无声AudioFlinger或HAL线程卡死logcat查AudioMTKStreamManagerANRdump线程栈检查有无死锁或blocked I/O这张表并不是什么高深的理论它本质上就是把排查过程中的常见“断点”按模块汇总。你可以把它打印出来贴在工位上遇到无声问题先对号入座很多问题在第一个回合就能定方向。5. 音频路径配置修改时的注意事项与复盘经验5.1 改audio_policy_configuration.xml前先备份和梳理依赖音频路径配置不是改一个文件就完事。audio_policy_configuration.xml改动后往往后面跟着一连串联动变化audio_device.xml中的device映射、AudioPolicyManager里对应strategy的设置、甚至AudioFlinger对输出profile的支持。MTK平台的audio_policy_configuration.xml里面会引用大量attachedDevices和availableDevices这些device name与audio_device.xml里的定义必须一一对应名字对不上轻则route失败重则整个AudioService都起不来。建议任何改动前先做一个全局搜索看看所有要改的device name在几个文件中出现过。我见过太多人只改了主文件忘了动audio_policy_engine_config.xml结果系统起来后路由到新设备时直接找不到设备id报错半天也不知道原因。改之前备份原文件只是一个基本操作更重要的是要能说清楚“为什么这个device要这样改、改完会影响哪个场景”。如果你说不出来那这个改动建议先缓一缓。5.2 MTK平台常用的调试接口和底层日志抓取方法MTK的Audio调试有一个很实用的体系也就是AudioDebugService和底层audio的sysfs接口。具体来说在/sys/kernel/debug/mtk_audio/下有几个子目录分别对应audio的mem、clock、dai、device等状态。这些接口在无声问题排查中尤其管用。比如当怀疑底层通路没打开时可以查看这个目录下的audio_dai状态确认DL1、DL2、UL1等数据通路是否处于START状态。另外MTK平台的Audio HAL层日志可以通过属性来动态开启。常见的属性有setprop vendor.audio.dump.pcm 1 setprop vendor.audio.hal.debug 1第一个属性用于打开PCM数据dump功能开启后在/sdcard/mtklog/audio_dump/下会生成录音和播放的PCM Dump文件。这个功能在排查“数据有没有送到HAL层”时非常有用。如果dump出来的PCM文件在PC上播放正常说明数据源没问题如果播放是噪声说明上层数据已经异常如果dump文件本身就是空的说明根本没有数据送下来。第二个属性则会让Audio HAL打印更多内部调试信息。还有一个比较实用的思路是开启logcat -b all抓完整日志但抓完后不要整段去看推荐先按Audio*关键字过滤出核心链路再按时间线逐行核对。MTK平台上Audio模块的日志量很大不按关键字过滤的话根本看不出问题的主线。5.3 一句话经验先确认数据和路由再动硬件配置最后分享一个我自己踩过不少坑后总结出来的经验排查MTK音频无声问题不要轻易怀疑硬件也不要轻易去改配置。硬件问题在MTK方案中出现概率远低于软件与配置。正确做法是先通过tinyplay/PCM dump确认“数据有没有送到CPU侧”再通过tinymix/codec状态确认“数据有没有从codec送到喇叭”。只要这两点确认了硬件就是好的问题一定在中间的音频路径配置上。我见过一个最耗时的案例同事花了三天时间反复修改audio_policy_configuration.xml里的采样率和格式都没解决问题。后来我帮他用tinyplay直接播放测试发现底层也是无声再查tinymix发现Speaker的PA enable引脚压根没拉高。最后查dts结果是pa-supply配置里通道名多了一个下划线。三天的问题最终只是字符匹配失败的苦笑结局。所以每次排查都要有一个心理预期MTK平台的配置文件和代码本来就绕字符错一点、格式差一点表现出来就是无声。正因为如此认真走完一遍底层链路验证再动手改配置往往会比你从上层开始频繁试错要快得多。如果你目前正好卡在某个音频无声问题上建议先静下心按这篇文章的流程走一遍。先从dumpsys看清上层状态再抓log确认路由然后tinyplay验证底层最后查codec状态。每一步都搞清楚“为什么无声”的证据链基本都能找到问题所在。