调试记录做到第15篇终于轮到Audio了。全志T527这颗SoC的音频子系统说复杂不算复杂——无非是DAUDIO走I2S/TDM把数字音频送给外置Codec或者直接走PDM接数字麦再或者用内置Codec输给功放推喇叭。但在BSP调试里Audio几乎每次都能让我多加班两小时问题往往不在内核驱动而在设备树缺一个GPIO、ALSA通路里某一级Mux没切对、主时钟的倍率算错。这篇文章没法帮你把每一颗Codec的引脚都查清楚但能把思路理清配合T527上的实际操作覆盖从设备树配到tinyplay出声的完整链路也包括无声、爆音、变调这一类问题的排查方法。如果你和我一样正在做全志平台的BSP或系统集成尤其是拿了新板子喇叭不响的这篇应该能直接当排查手册用。1. 先理清T527的音频链路三个角色一段声音的旅程1.1 板卡上的声音是怎么从SoC走到喇叭的我接触过的不少工程师一上来就抱着Codec数据手册查寄存器这没错但容易忽略一个前提你查的那个寄存器未必是当前信号真正经过的路径。音频调试和网络调试有点像你得先知道数据从哪来、要到哪去中间经过哪些设备才能判断问题出在哪一段。在T527的板卡上一条典型的声音链路长这样SoC内部的DMA把音频数据送到DAUDIO控制器DAUDIO按I2S时序把数据通过BCLK、LRCK、DOUT这几根线发给外置CodecCodec完成DAC转换后输出模拟信号送到功放PA最后驱动喇叭。反过来录音就是反方向MIC拾音后经Codec的ADC变成数字信号再通过DIUT线回到DAUDIO控制器DMA搬运到内存里。这里面的关键认知是三根线的角色完全不同。BCLK是位时钟决定每一位数据什么时候被采样LRCK是左右声道切换信号告诉接收方当前这一帧属于左声道还是右声道DOUT/DIUT就是数据线。很多I2S对不上、声音变调、左右声道反了的问题最后都能追溯到这三根线的时序参数上。1.2 I2S、PDM与内置CodecT527平台常见的三种走法T527的音频接口资源比较丰富我简单分三类。第一类是DAUDIO接口本质上是可以配置成I2S、PCM或者TDM的控制器。做智能音箱、语音板卡时经常用它外接一颗高精度Codec比如ES8388、WM8960这类支持的路数多音质也容易做上去。调试这类方案时要关注的寄存器最多但信号链路最清晰很适合用来讲原理。第二类是PDM接口直接接数字麦克风。PDM只有两根线一根时钟一根数据麦克风内部已经完成采样传出来的是经过调制的数字信号。好处是省掉了Codec坏处是如果你想做录音通路调试能下手的地方更少基本只能查时钟有没有给到、数据线有没有接对。第三类是内置Codec。部分全志方案会集成一路简单的Audio Codec板子上不需要再接外部芯片直接通过内部寄存器配置混音、增益、功放就行。T527的板卡设计比较多样有的方案就走了内置Codec加外部D类功放。这类方案省成本但内部混音路径是固定的碰到奇怪问题时往往没什么可改的只能围绕寄存器去查。1.3 链路三段论把调试对象切成可隔离的模块我习惯把Audio调试拆成三段数字源段、Codec段、功放输出段。数字源段指从应用层/wav文件到DAUDIO控制器这一整块出现问题时的典型表现是tinyplay播放卡住不返回、打开PCM设备失败、或者播放速度异常。Codec段指从I2S接口到模拟输出这一段典型表现是播放时间正常、数据流也正常但输出是静音或严重失真。功放输出段指从Codec模拟输出到喇叭典型表现是Codec的输出引脚用示波器能测到波形但喇叭就是没声或者声音小到几乎听不见。这三段之间没有严格的分界线但排查的时候一定要先把问题归类到某一段。实际调试中我见过太多人一上来就抱着Codec数据手册查寄存器结果根本是PA使能脚没拉高这属于最典型的“方向错了”。2. 设备树与声卡注册先让Linux“看见”音频设备2.1 最小设备树配置DAUDIO、Codec与sound节点怎么写全志平台用标准ASoC框架设备树上必须存在三个关键角色CPU侧DAUDIO节点、Codec节点、以及一个把两者绑起来的sound节点。以我这次调试用的外接ES8388方案为例最小配置大概是这样的daudio0 { pinctrl-names default; pinctrl-0 daudio0_pins_a; mclk-fs 256; status okay; }; i2c0 { es8388: es838810 { compatible everest,es8388; reg 0x10; clocks clk_audio; reset-gpios pio 2 5 GPIO_ACTIVE_LOW; }; }; sound { compatible simple-audio-card; simple-audio-card,name t527-audio; simple-audio-card,format i2s; simple-audio-card,mclk-fs 256; simple-audio-card,cpu { sound-dai daudio0; }; simple-audio-card,codec { sound-dai es8388; }; };这里有几个点容易踩坑。第一reg 0x10必须和Codec芯片的实际I2C地址一致ES8388的地址由AD0/AD1引脚决定常见是0x10或0x11查原理图确认一下最稳妥。第二clocks clk_audio这里引用的时钟节点如果没配好驱动的probe可能直接失败日志里报EPROBE_DEFER。第三mclk-fs 256表示 MCLK 采样率 × 256这个值必须和Codec的输入时钟范围匹配后面我会专门讲。2.2 启动日志与proc节点确认注册成功的四步检查法设备树配置完重新烧录内核启动后先别急着去播放按顺序做四个检查。第一看内核日志里有没有和audio/codec相关的报错dmesg | grep -iE es8388|codec|daudio|asoc第二确认Codec的probe有没有成功正常能看到类似es8388 0-0010: ASoC: codec ... registered的日志。第三查看声卡是否注册成功cat /proc/asound/cards正常会看到类似0 [t527audio ]: t527-audio - t527-audio t527-audio第四确认PCM设备存在cat /proc/asound/pcm如果能看到至少一个playback设备说明内核侧的链路已经建立可以进入用户态调试了。这一套流程我每次都走一遍不是为了形式主义而是为了把问题范围快速缩小。很多时候声卡注册失败是设备树节点里的compatible写错、I2C地址不对、或者reset引脚拉死了Codec——这些都是几秒钟就能从日志里看出来的事没必要靠猜。2.3 声卡没起来的常见原因如果cat /proc/asound/cards显示空或者声卡注册了但子设备不完整我归纳下来最常见的三个原因一是Codec芯片压根没上电或没复位。调试时先量一下Codec供电引脚电压再确认reset GPIO的动作时序是否符合数据手册。有的Codec要求上电之后延迟几十毫秒再释放reset否则第一次I2C读取就会失败。二是I2C通信异常。可以从用户态直接探测一下Codec是否响应比如ES8388的寄存器0x00正常能读到0x00或0x01之类的内容i2ctransfer -f -y 0 w20x10 0x00 0x00 r1如果返回空或者报错先查I2C地址和设备树是否匹配。我遇到过很多次是原理图上挂了多个相同地址的设备I2C总线冲突导致Codec一直不能正常访问。三是设备树里CPU侧的DAUDIO节点没配pinmux。全志的引脚功能需要pinctrl-0显式配置少了这一句I2S数据根本到不了Codec代码层面看起来一切正常但就是没声。这类问题最坑因为日志不会报错只能靠检查设备树。3. 用户态三板斧从tinypcminfo到tinyplay跑通第一声3.1 为什么全志BSP里几乎都用tinyalsa拿到一个跑通的声卡下一步就是上面板测试。全志的BSP里通常集成的是tinyalsa而不是完整的alsa-utils原因很简单tinyalsa足够轻量而且功能对于调试来说完全够用。tinypcminfo看PCM参数amixer控制通路和增益tinyplay播放tinycap录音四件套就够了。这跟PC上遇到的“无法启动Windows Audio服务”完全是两码事——嵌入式Linux没有常驻的音频服务你调的就是内核ALSA框架本身。所以别拿Windows那一套经验硬套工具链完全不同。3.2 实测流程三条命令让系统出声声卡注册成功后我习惯按这个顺序来# 1. 查看PCM设备支持的格式 tinypcminfo -D hw:0,0这一步确认采样率范围、通道数、位深。很多板子的Codec或DAUDIO控制器对格式有限制比如只支持16bit/48kHz。看到的参数记下来后面做测试音频文件用。# 2. 查看当前声卡的kcontrol列表 amixer -D hw:0 contents这一步把当前所有控制项的当前值打出来重点看Playback相关的Volume、Switch、Mux有没有处于零或关闭状态。我强烈建议每次调试前都留一份这个输出存档后面改了什么一对比就清楚。# 3. 播放测试音频 tinyplay /tmp/test.wav -D hw:0,0如果这一步直接出声了恭喜基础链路已经通了。接下来要做的就是把音量、通路、采样率等参数固化到启动脚本里避免每次重启都重新配置。如果没声先别急着重启继续往下排查。3.3 kcontrol与DAPM通路为什么amixer拨了半天还是静音很多工程师卡在“播放时间正常但没声音”的状态里其实是因为忽视了ALSA的动态音频电源管理DAPM。DAPM会在播放时根据音频路径动态上电、下电各个widget只有信号经过的路径上有相应的开关和Mux配置正确Codec内部才会真的把信号送到输出引脚。我用一个生活化的类比DAPM路径就像城市道路的红绿灯数据流是车辆。车辆在跑但如果某一路口的红绿灯始终是红的车就到不了目的地。amixer里的那些Mux、Mixer Switch就是这些红绿灯。以ES8388为例你要把DAC的信号最终送到耳机或喇叭输出往往需要同时打开好几级通路DAC到输出混音器的开关、输出混音器到对应输出引脚的开关、以及最后那级输出音量控制。只开音量、不开通路照样静音。如果你不确定需要开哪些控制项一个土办法是插上耳机或接上示波器用amixer把能看到的Switch逐个打开、逐个试。这不是聪明的做法但在没有参考配置的时候确实有效。更专业的做法是去Codec数据手册里查信号流程图按图把每条路径的开关列出来。调试经验积累之后你会发现ES8388、WM8960这类Codec的路径设计思路其实都很类似无非DAC→Mixer→Output这一条主线。4. 无声问题的完整排查链路从上层到硬件逐级定位4.1 先给现象分类不同表现对应不同链路段拿到“没声音”的报告我的第一反应是问现象细节因为不同现象指向的问题段完全不同。第一种tinyplay打开设备直接报错或者卡住不返回。这基本说明问题出在数字源段或驱动注册段比如PCM参数不匹配、DMA通道没配置好、声卡子设备异常。第二种播放正常结束、进度正常但喇叭完全没声。这是最常见的情况问题出在Codec路径或功放段重点查DAPM通路、音量寄存器、PA使能信号。第三种有声音但伴随明显的爆音、杂音或失真。问题往往在I2S时钟配置、电源纹波、或者数字/模拟增益配得太高。第四种播放速度不对本来10秒的歌几秒放完或者音调明显偏高。这种几乎都是采样率配置错误后面第五章单独讲。拿到现象分类后我习惯按信号流向逐段排查从软件能控制的最上游开始一路测到物理输出。4.2 一个真实案例tinyplay正常结束但喇叭不出声前段时间调一块T527板卡外接ES8388加一颗D类功放现象就是典型的第二种tinyplay播放正常结束耳机孔接上也没声音喇叭更没声音。我的排查顺序是这样的。第一步确认用户态到内核的状态正常。tinypcminfo -D hw:0,0和tinyplay都正常执行说明PCM设备没问题DMA也确实把数据送出去了。这里要记住一个结论播放不报错只能说明数据到了DAUDIO控制器不代表Codec收到了正确信号。第二步检查I2S总线上有没有信号。用示波器量DAUDIO到Codec之间的BCLK、LRCK、DOUT。我这次量后发现DOUT有数据BCLK和LRCK也都有基本确定SoC侧没问题问题在Codec或更下游。第三步进入Codec寄存器排查。用I2C工具读一下ES8388几个关键寄存器主要看DAC是否处于上电状态、输出通路开关、以及音量寄存器。我读到的寄存器值显示DAC在跑但输出混音器到耳机的通路没有完全打开音量寄存器虽然不为零但很小。第四步补上正确的通路配置。用amixer把所有需要的Mux切到正确输入源把Output Mixer开关打开然后重新播放测试音频耳机里终于出声了。4.3 排查链路的“临门一脚”PA使能与硬件末端检查耳机出声后喇叭仍然不响。这说明链路已经被推进到了功放段。我让硬件同事量了一下Codec输出引脚波形是正常的但功放芯片的使能脚EN电压始终是0V这就很说明问题了功放被静音了。查了一下设备树发现这颗功放的EN引脚在主控侧对应的GPIO根本没有配置输出高电平。这是非常典型的问题设计上PA使能由某个GPIO控制但软件侧没实现或者实现了但没调用。处理方式就是把这个GPIO加到Codec驱动或板级配置里或者直接在系统启动脚本里把它拉高echo 1 /sys/class/gpio/gpioXXX/value不过这只是应急手段正规做法还是改设备树让驱动在声卡启动时自动控制PA的时序。很多功放要求先给模拟信号、再拉高EN反过来会有开机爆音具体时序看功放数据手册。这轮排查下来我最大的体会是问题定位速度取决于你能不能把问题精确切成“数字源段—Codec段—功放段”三块。每次只怀疑一段验证一段不要同时改三个地方。5. 采样率、主时钟与增益声音出来以后真正的坑才刚开始5.1 MCLK/BCLK/LRCK的匹配逻辑声音出来只是第一步后面接踵而来的才是真正的坑尤其是时钟配置和增益这两个话题。MCLK这个信号很多人会忽略。它是Codec内部数字信号处理的主时钟不是I2S标准必需的三根线之一。T527的DAUDIO控制器通常会输出一路MCLK给Codec频率通常是采样率的整数倍常见的是256倍或512倍。设备树里的mclk-fs 256就是这个意思。举个例子采样率是48kHz时MCLK应该是 48000 × 256 12.288MHz采样率是44.1kHz时MCLK是 44100 × 256 11.2896MHz。如果你发现44.1kHz的音频播放时音调偏高、速度偏快大概率是Codec实际用的MCLK还是48kHz对应的频率或者系统把它统一配置成了某一个固定频率。BCLK和LRCK则和位深、通道数直接相关。对于双声道、16bit、I2S格式LRCK频率等于采样率BCLK频率等于 采样率 × 位深 × 通道数。更高的位深或通道数会成倍提高BCLK所以改格式后声音异常先回去确认这几项参数是否联动伴改。我把常用的对应关系整理成表方便速查采样率MCLK (mclk-fs256)MCLK (mclk-fs512)BCLK (16bit/双声道)44.1kHz11.2896MHz22.5792MHz1.4112MHz48kHz12.288MHz24.576MHz1.536MHz96kHz24.576MHz49.152MHz3.072MHz5.2 数字增益和模拟增益如何搭配不爆音音量控制是最直观的调试项但恰恰是它最容易把人带沟里。全志平台和Codec驱动里通常会有两级增益数字域增益DAC Digital Volume和模拟域增益Line Out/Headphone Amp Volume。很多人一上来就把两者都拉满结果喇叭传出明显的爆音和削波失真。我的习惯是遵循“数字留余量、模拟定基调”的策略。先把数字增益固定在-15dB左右然后用模拟增益调整到合适音量。这样做的原因是数字增益接近满刻度时一旦上游音频文件本身碰到0dBFSDAC那边就会硬削波这种失真在模拟端是永远修不回来的。实测下来这个策略的效果很明显。之前一块板子同事把数字增益调到0dB后播放高动态范围的音乐低音部分会明显发破按照“数字留余量”调低之后声音干净很多响度也没有实际降低多少因为模拟增益还有足够余量补回来。如果录音有类似问题ADC那边的数字增益也是同样的道理。麦克风输入信号本身就有本底噪声数字增益拉太高会把底噪一起放大这时候宁可调大模拟前端的MIC Boost也要压低数字增益。5.3 采样率配置不一致变调和播放时长不对的元凶另一个高频问题就是采样率配置不一致。我遇到过一个案例播放44.1kHz采样率的WAV声音发尖、明显变快整个曲子时长缩短。查到最后发现是应用层通过tinyplay播放时参数协商出来的rate一直是48kHzCodec和DAUDIO都按48kHz来跑把44.1kHz的数据强行按48kHz时钟读出来音调自然就高了。这种问题的排查思路是先确认音频文件本身的采样率再看tinyplay协商出来的实际采样率。tinypcminfo -D hw:0,0可以看到硬件支持的rate范围多数的Codec支持44.1kHz和48kHz但有些低成本Codec只支持48kHz如果音频文件是44.1kHz而硬件只支持48kHz就需要在应用层做重采样而不是硬放。我做的测试音频文件一般会固定生成两个版本一个44.1kHz/16bit/双声道一个48kHz/16bit/双声道哪边能正常就说明链路这边的时钟基本没毛病ffmpeg -f lavfi -i sinefrequency1000:duration2 -ar 44100 -ac 2 /tmp/test_44k.wav ffmpeg -f lavfi -i sinefrequency1000:duration2 -ar 48000 -ac 2 /tmp/test_48k.wav1kHz正弦波的好处是如果音调变了人耳一耳朵就能分辨出来如果失真或爆音也容易听出来。比起直接放一首歌用测试音定位问题要靠谱得多。6. 把“最小可出声配置”固化成你的调试资产6.1 我的Audio调试检查单做过一轮完整调试之后我会把这次所有有效命令和参数整理成一个检查单每块新板子回来先照单跑一遍。这里分享出来供参考确认设备树中CPU侧DAUDIO、Codec、sound三个节点都正常/proc/asound/cards能看到声卡。用tinypcminfo -D hw:0,0确认PCM参数确认硬件支持你将要测试的采样率。用amixer -D hw:0 contents导出一份当前所有kcontrol的状态存档。配置Codec通路把DAC/ADC对应的Mixer、Mux、Switch都打到正确方向音量先放保守值。播放44.1kHz和48kHz两路1kHz测试音听音调、听破音。确认PA使能GPIO、各类电源轨、Codec MCLK的波形都在正常工作范围。全部通过后把amixer设置整理成开机自启动脚本并记录内核日志基线。这套检查单跑下来大概五分钟就能完成但它能帮我快速区分“新板子硬件有问题”和“软件还没配好”后面再深入调试就有底气多了。6.2 测试音频文件的小讲究最后说一个很小但很实用的细节不要随便在网上下载一首MP3转成WAV来测试。MP3本身的编码、转码后的位深、声道数都可能引入变量干扰判断。我的做法是固定用ffmpeg生成1kHz正弦波、扫频波和粉红噪声三种文件分别用于音调判断、频响感知和底噪检查。扫频文件尤其好用。如果Codec的某些频点滤波配置有问题扫频播放时就能明显听到某一段音量突然跌落。这一类问题用歌曲测试很容易被忽略用扫频信号一耳朵就能抓出来。调试Audio的过程很像是在给声音数据当交通警察每个路口都要确认能不能走、该不该停。T527的平台架构还算规整只要按照链路一段一段排查多数问题都能在半小时内定位。反而是那些“看起来全正常但就是没声”的局往往败在某个不到位的GPIO或某个没打开的Mux上。把检查单跑熟练把最小可出声配置沉淀成脚本以后每块板子回来都会轻松很多。
全志T527音频调试实战：从设备树到tinyplay的完整链路排查
调试记录做到第15篇终于轮到Audio了。全志T527这颗SoC的音频子系统说复杂不算复杂——无非是DAUDIO走I2S/TDM把数字音频送给外置Codec或者直接走PDM接数字麦再或者用内置Codec输给功放推喇叭。但在BSP调试里Audio几乎每次都能让我多加班两小时问题往往不在内核驱动而在设备树缺一个GPIO、ALSA通路里某一级Mux没切对、主时钟的倍率算错。这篇文章没法帮你把每一颗Codec的引脚都查清楚但能把思路理清配合T527上的实际操作覆盖从设备树配到tinyplay出声的完整链路也包括无声、爆音、变调这一类问题的排查方法。如果你和我一样正在做全志平台的BSP或系统集成尤其是拿了新板子喇叭不响的这篇应该能直接当排查手册用。1. 先理清T527的音频链路三个角色一段声音的旅程1.1 板卡上的声音是怎么从SoC走到喇叭的我接触过的不少工程师一上来就抱着Codec数据手册查寄存器这没错但容易忽略一个前提你查的那个寄存器未必是当前信号真正经过的路径。音频调试和网络调试有点像你得先知道数据从哪来、要到哪去中间经过哪些设备才能判断问题出在哪一段。在T527的板卡上一条典型的声音链路长这样SoC内部的DMA把音频数据送到DAUDIO控制器DAUDIO按I2S时序把数据通过BCLK、LRCK、DOUT这几根线发给外置CodecCodec完成DAC转换后输出模拟信号送到功放PA最后驱动喇叭。反过来录音就是反方向MIC拾音后经Codec的ADC变成数字信号再通过DIUT线回到DAUDIO控制器DMA搬运到内存里。这里面的关键认知是三根线的角色完全不同。BCLK是位时钟决定每一位数据什么时候被采样LRCK是左右声道切换信号告诉接收方当前这一帧属于左声道还是右声道DOUT/DIUT就是数据线。很多I2S对不上、声音变调、左右声道反了的问题最后都能追溯到这三根线的时序参数上。1.2 I2S、PDM与内置CodecT527平台常见的三种走法T527的音频接口资源比较丰富我简单分三类。第一类是DAUDIO接口本质上是可以配置成I2S、PCM或者TDM的控制器。做智能音箱、语音板卡时经常用它外接一颗高精度Codec比如ES8388、WM8960这类支持的路数多音质也容易做上去。调试这类方案时要关注的寄存器最多但信号链路最清晰很适合用来讲原理。第二类是PDM接口直接接数字麦克风。PDM只有两根线一根时钟一根数据麦克风内部已经完成采样传出来的是经过调制的数字信号。好处是省掉了Codec坏处是如果你想做录音通路调试能下手的地方更少基本只能查时钟有没有给到、数据线有没有接对。第三类是内置Codec。部分全志方案会集成一路简单的Audio Codec板子上不需要再接外部芯片直接通过内部寄存器配置混音、增益、功放就行。T527的板卡设计比较多样有的方案就走了内置Codec加外部D类功放。这类方案省成本但内部混音路径是固定的碰到奇怪问题时往往没什么可改的只能围绕寄存器去查。1.3 链路三段论把调试对象切成可隔离的模块我习惯把Audio调试拆成三段数字源段、Codec段、功放输出段。数字源段指从应用层/wav文件到DAUDIO控制器这一整块出现问题时的典型表现是tinyplay播放卡住不返回、打开PCM设备失败、或者播放速度异常。Codec段指从I2S接口到模拟输出这一段典型表现是播放时间正常、数据流也正常但输出是静音或严重失真。功放输出段指从Codec模拟输出到喇叭典型表现是Codec的输出引脚用示波器能测到波形但喇叭就是没声或者声音小到几乎听不见。这三段之间没有严格的分界线但排查的时候一定要先把问题归类到某一段。实际调试中我见过太多人一上来就抱着Codec数据手册查寄存器结果根本是PA使能脚没拉高这属于最典型的“方向错了”。2. 设备树与声卡注册先让Linux“看见”音频设备2.1 最小设备树配置DAUDIO、Codec与sound节点怎么写全志平台用标准ASoC框架设备树上必须存在三个关键角色CPU侧DAUDIO节点、Codec节点、以及一个把两者绑起来的sound节点。以我这次调试用的外接ES8388方案为例最小配置大概是这样的daudio0 { pinctrl-names default; pinctrl-0 daudio0_pins_a; mclk-fs 256; status okay; }; i2c0 { es8388: es838810 { compatible everest,es8388; reg 0x10; clocks clk_audio; reset-gpios pio 2 5 GPIO_ACTIVE_LOW; }; }; sound { compatible simple-audio-card; simple-audio-card,name t527-audio; simple-audio-card,format i2s; simple-audio-card,mclk-fs 256; simple-audio-card,cpu { sound-dai daudio0; }; simple-audio-card,codec { sound-dai es8388; }; };这里有几个点容易踩坑。第一reg 0x10必须和Codec芯片的实际I2C地址一致ES8388的地址由AD0/AD1引脚决定常见是0x10或0x11查原理图确认一下最稳妥。第二clocks clk_audio这里引用的时钟节点如果没配好驱动的probe可能直接失败日志里报EPROBE_DEFER。第三mclk-fs 256表示 MCLK 采样率 × 256这个值必须和Codec的输入时钟范围匹配后面我会专门讲。2.2 启动日志与proc节点确认注册成功的四步检查法设备树配置完重新烧录内核启动后先别急着去播放按顺序做四个检查。第一看内核日志里有没有和audio/codec相关的报错dmesg | grep -iE es8388|codec|daudio|asoc第二确认Codec的probe有没有成功正常能看到类似es8388 0-0010: ASoC: codec ... registered的日志。第三查看声卡是否注册成功cat /proc/asound/cards正常会看到类似0 [t527audio ]: t527-audio - t527-audio t527-audio第四确认PCM设备存在cat /proc/asound/pcm如果能看到至少一个playback设备说明内核侧的链路已经建立可以进入用户态调试了。这一套流程我每次都走一遍不是为了形式主义而是为了把问题范围快速缩小。很多时候声卡注册失败是设备树节点里的compatible写错、I2C地址不对、或者reset引脚拉死了Codec——这些都是几秒钟就能从日志里看出来的事没必要靠猜。2.3 声卡没起来的常见原因如果cat /proc/asound/cards显示空或者声卡注册了但子设备不完整我归纳下来最常见的三个原因一是Codec芯片压根没上电或没复位。调试时先量一下Codec供电引脚电压再确认reset GPIO的动作时序是否符合数据手册。有的Codec要求上电之后延迟几十毫秒再释放reset否则第一次I2C读取就会失败。二是I2C通信异常。可以从用户态直接探测一下Codec是否响应比如ES8388的寄存器0x00正常能读到0x00或0x01之类的内容i2ctransfer -f -y 0 w20x10 0x00 0x00 r1如果返回空或者报错先查I2C地址和设备树是否匹配。我遇到过很多次是原理图上挂了多个相同地址的设备I2C总线冲突导致Codec一直不能正常访问。三是设备树里CPU侧的DAUDIO节点没配pinmux。全志的引脚功能需要pinctrl-0显式配置少了这一句I2S数据根本到不了Codec代码层面看起来一切正常但就是没声。这类问题最坑因为日志不会报错只能靠检查设备树。3. 用户态三板斧从tinypcminfo到tinyplay跑通第一声3.1 为什么全志BSP里几乎都用tinyalsa拿到一个跑通的声卡下一步就是上面板测试。全志的BSP里通常集成的是tinyalsa而不是完整的alsa-utils原因很简单tinyalsa足够轻量而且功能对于调试来说完全够用。tinypcminfo看PCM参数amixer控制通路和增益tinyplay播放tinycap录音四件套就够了。这跟PC上遇到的“无法启动Windows Audio服务”完全是两码事——嵌入式Linux没有常驻的音频服务你调的就是内核ALSA框架本身。所以别拿Windows那一套经验硬套工具链完全不同。3.2 实测流程三条命令让系统出声声卡注册成功后我习惯按这个顺序来# 1. 查看PCM设备支持的格式 tinypcminfo -D hw:0,0这一步确认采样率范围、通道数、位深。很多板子的Codec或DAUDIO控制器对格式有限制比如只支持16bit/48kHz。看到的参数记下来后面做测试音频文件用。# 2. 查看当前声卡的kcontrol列表 amixer -D hw:0 contents这一步把当前所有控制项的当前值打出来重点看Playback相关的Volume、Switch、Mux有没有处于零或关闭状态。我强烈建议每次调试前都留一份这个输出存档后面改了什么一对比就清楚。# 3. 播放测试音频 tinyplay /tmp/test.wav -D hw:0,0如果这一步直接出声了恭喜基础链路已经通了。接下来要做的就是把音量、通路、采样率等参数固化到启动脚本里避免每次重启都重新配置。如果没声先别急着重启继续往下排查。3.3 kcontrol与DAPM通路为什么amixer拨了半天还是静音很多工程师卡在“播放时间正常但没声音”的状态里其实是因为忽视了ALSA的动态音频电源管理DAPM。DAPM会在播放时根据音频路径动态上电、下电各个widget只有信号经过的路径上有相应的开关和Mux配置正确Codec内部才会真的把信号送到输出引脚。我用一个生活化的类比DAPM路径就像城市道路的红绿灯数据流是车辆。车辆在跑但如果某一路口的红绿灯始终是红的车就到不了目的地。amixer里的那些Mux、Mixer Switch就是这些红绿灯。以ES8388为例你要把DAC的信号最终送到耳机或喇叭输出往往需要同时打开好几级通路DAC到输出混音器的开关、输出混音器到对应输出引脚的开关、以及最后那级输出音量控制。只开音量、不开通路照样静音。如果你不确定需要开哪些控制项一个土办法是插上耳机或接上示波器用amixer把能看到的Switch逐个打开、逐个试。这不是聪明的做法但在没有参考配置的时候确实有效。更专业的做法是去Codec数据手册里查信号流程图按图把每条路径的开关列出来。调试经验积累之后你会发现ES8388、WM8960这类Codec的路径设计思路其实都很类似无非DAC→Mixer→Output这一条主线。4. 无声问题的完整排查链路从上层到硬件逐级定位4.1 先给现象分类不同表现对应不同链路段拿到“没声音”的报告我的第一反应是问现象细节因为不同现象指向的问题段完全不同。第一种tinyplay打开设备直接报错或者卡住不返回。这基本说明问题出在数字源段或驱动注册段比如PCM参数不匹配、DMA通道没配置好、声卡子设备异常。第二种播放正常结束、进度正常但喇叭完全没声。这是最常见的情况问题出在Codec路径或功放段重点查DAPM通路、音量寄存器、PA使能信号。第三种有声音但伴随明显的爆音、杂音或失真。问题往往在I2S时钟配置、电源纹波、或者数字/模拟增益配得太高。第四种播放速度不对本来10秒的歌几秒放完或者音调明显偏高。这种几乎都是采样率配置错误后面第五章单独讲。拿到现象分类后我习惯按信号流向逐段排查从软件能控制的最上游开始一路测到物理输出。4.2 一个真实案例tinyplay正常结束但喇叭不出声前段时间调一块T527板卡外接ES8388加一颗D类功放现象就是典型的第二种tinyplay播放正常结束耳机孔接上也没声音喇叭更没声音。我的排查顺序是这样的。第一步确认用户态到内核的状态正常。tinypcminfo -D hw:0,0和tinyplay都正常执行说明PCM设备没问题DMA也确实把数据送出去了。这里要记住一个结论播放不报错只能说明数据到了DAUDIO控制器不代表Codec收到了正确信号。第二步检查I2S总线上有没有信号。用示波器量DAUDIO到Codec之间的BCLK、LRCK、DOUT。我这次量后发现DOUT有数据BCLK和LRCK也都有基本确定SoC侧没问题问题在Codec或更下游。第三步进入Codec寄存器排查。用I2C工具读一下ES8388几个关键寄存器主要看DAC是否处于上电状态、输出通路开关、以及音量寄存器。我读到的寄存器值显示DAC在跑但输出混音器到耳机的通路没有完全打开音量寄存器虽然不为零但很小。第四步补上正确的通路配置。用amixer把所有需要的Mux切到正确输入源把Output Mixer开关打开然后重新播放测试音频耳机里终于出声了。4.3 排查链路的“临门一脚”PA使能与硬件末端检查耳机出声后喇叭仍然不响。这说明链路已经被推进到了功放段。我让硬件同事量了一下Codec输出引脚波形是正常的但功放芯片的使能脚EN电压始终是0V这就很说明问题了功放被静音了。查了一下设备树发现这颗功放的EN引脚在主控侧对应的GPIO根本没有配置输出高电平。这是非常典型的问题设计上PA使能由某个GPIO控制但软件侧没实现或者实现了但没调用。处理方式就是把这个GPIO加到Codec驱动或板级配置里或者直接在系统启动脚本里把它拉高echo 1 /sys/class/gpio/gpioXXX/value不过这只是应急手段正规做法还是改设备树让驱动在声卡启动时自动控制PA的时序。很多功放要求先给模拟信号、再拉高EN反过来会有开机爆音具体时序看功放数据手册。这轮排查下来我最大的体会是问题定位速度取决于你能不能把问题精确切成“数字源段—Codec段—功放段”三块。每次只怀疑一段验证一段不要同时改三个地方。5. 采样率、主时钟与增益声音出来以后真正的坑才刚开始5.1 MCLK/BCLK/LRCK的匹配逻辑声音出来只是第一步后面接踵而来的才是真正的坑尤其是时钟配置和增益这两个话题。MCLK这个信号很多人会忽略。它是Codec内部数字信号处理的主时钟不是I2S标准必需的三根线之一。T527的DAUDIO控制器通常会输出一路MCLK给Codec频率通常是采样率的整数倍常见的是256倍或512倍。设备树里的mclk-fs 256就是这个意思。举个例子采样率是48kHz时MCLK应该是 48000 × 256 12.288MHz采样率是44.1kHz时MCLK是 44100 × 256 11.2896MHz。如果你发现44.1kHz的音频播放时音调偏高、速度偏快大概率是Codec实际用的MCLK还是48kHz对应的频率或者系统把它统一配置成了某一个固定频率。BCLK和LRCK则和位深、通道数直接相关。对于双声道、16bit、I2S格式LRCK频率等于采样率BCLK频率等于 采样率 × 位深 × 通道数。更高的位深或通道数会成倍提高BCLK所以改格式后声音异常先回去确认这几项参数是否联动伴改。我把常用的对应关系整理成表方便速查采样率MCLK (mclk-fs256)MCLK (mclk-fs512)BCLK (16bit/双声道)44.1kHz11.2896MHz22.5792MHz1.4112MHz48kHz12.288MHz24.576MHz1.536MHz96kHz24.576MHz49.152MHz3.072MHz5.2 数字增益和模拟增益如何搭配不爆音音量控制是最直观的调试项但恰恰是它最容易把人带沟里。全志平台和Codec驱动里通常会有两级增益数字域增益DAC Digital Volume和模拟域增益Line Out/Headphone Amp Volume。很多人一上来就把两者都拉满结果喇叭传出明显的爆音和削波失真。我的习惯是遵循“数字留余量、模拟定基调”的策略。先把数字增益固定在-15dB左右然后用模拟增益调整到合适音量。这样做的原因是数字增益接近满刻度时一旦上游音频文件本身碰到0dBFSDAC那边就会硬削波这种失真在模拟端是永远修不回来的。实测下来这个策略的效果很明显。之前一块板子同事把数字增益调到0dB后播放高动态范围的音乐低音部分会明显发破按照“数字留余量”调低之后声音干净很多响度也没有实际降低多少因为模拟增益还有足够余量补回来。如果录音有类似问题ADC那边的数字增益也是同样的道理。麦克风输入信号本身就有本底噪声数字增益拉太高会把底噪一起放大这时候宁可调大模拟前端的MIC Boost也要压低数字增益。5.3 采样率配置不一致变调和播放时长不对的元凶另一个高频问题就是采样率配置不一致。我遇到过一个案例播放44.1kHz采样率的WAV声音发尖、明显变快整个曲子时长缩短。查到最后发现是应用层通过tinyplay播放时参数协商出来的rate一直是48kHzCodec和DAUDIO都按48kHz来跑把44.1kHz的数据强行按48kHz时钟读出来音调自然就高了。这种问题的排查思路是先确认音频文件本身的采样率再看tinyplay协商出来的实际采样率。tinypcminfo -D hw:0,0可以看到硬件支持的rate范围多数的Codec支持44.1kHz和48kHz但有些低成本Codec只支持48kHz如果音频文件是44.1kHz而硬件只支持48kHz就需要在应用层做重采样而不是硬放。我做的测试音频文件一般会固定生成两个版本一个44.1kHz/16bit/双声道一个48kHz/16bit/双声道哪边能正常就说明链路这边的时钟基本没毛病ffmpeg -f lavfi -i sinefrequency1000:duration2 -ar 44100 -ac 2 /tmp/test_44k.wav ffmpeg -f lavfi -i sinefrequency1000:duration2 -ar 48000 -ac 2 /tmp/test_48k.wav1kHz正弦波的好处是如果音调变了人耳一耳朵就能分辨出来如果失真或爆音也容易听出来。比起直接放一首歌用测试音定位问题要靠谱得多。6. 把“最小可出声配置”固化成你的调试资产6.1 我的Audio调试检查单做过一轮完整调试之后我会把这次所有有效命令和参数整理成一个检查单每块新板子回来先照单跑一遍。这里分享出来供参考确认设备树中CPU侧DAUDIO、Codec、sound三个节点都正常/proc/asound/cards能看到声卡。用tinypcminfo -D hw:0,0确认PCM参数确认硬件支持你将要测试的采样率。用amixer -D hw:0 contents导出一份当前所有kcontrol的状态存档。配置Codec通路把DAC/ADC对应的Mixer、Mux、Switch都打到正确方向音量先放保守值。播放44.1kHz和48kHz两路1kHz测试音听音调、听破音。确认PA使能GPIO、各类电源轨、Codec MCLK的波形都在正常工作范围。全部通过后把amixer设置整理成开机自启动脚本并记录内核日志基线。这套检查单跑下来大概五分钟就能完成但它能帮我快速区分“新板子硬件有问题”和“软件还没配好”后面再深入调试就有底气多了。6.2 测试音频文件的小讲究最后说一个很小但很实用的细节不要随便在网上下载一首MP3转成WAV来测试。MP3本身的编码、转码后的位深、声道数都可能引入变量干扰判断。我的做法是固定用ffmpeg生成1kHz正弦波、扫频波和粉红噪声三种文件分别用于音调判断、频响感知和底噪检查。扫频文件尤其好用。如果Codec的某些频点滤波配置有问题扫频播放时就能明显听到某一段音量突然跌落。这一类问题用歌曲测试很容易被忽略用扫频信号一耳朵就能抓出来。调试Audio的过程很像是在给声音数据当交通警察每个路口都要确认能不能走、该不该停。T527的平台架构还算规整只要按照链路一段一段排查多数问题都能在半小时内定位。反而是那些“看起来全正常但就是没声”的局往往败在某个不到位的GPIO或某个没打开的Mux上。把检查单跑熟练把最小可出声配置沉淀成脚本以后每块板子回来都会轻松很多。
