做嵌入式Linux开发的朋友应该都有这种体会用外部CodecES8388、WM8960、NAU88C22之类调音频时I2C读寄存器、看数据手册、用i2c-tools手动改两个寄存器都是常规操作。但第一次拿到全志T113这颗芯片翻遍参考设计发现I2C总线上根本没挂Codec硬件框图里却明明白白写着Audio Codec这时候很多人会愣一下。T113把音频编解码器直接集成进了SoC内部调试思路和外挂Codec完全不一样没有I2C寄存器可操作数字侧不走外部I2S引脚你能依赖的几乎只有内核ALSA框架导出的控件和设备树里那几行配置。这篇文章我把自己在全志T113平台上调通录音和播放的完整过程、踩过的坑、以及背后涉及的时钟和通路原理一次性整理出来希望对正在做T113方案或者手头有R328、T507这类同样内置Codec的全志平台的小伙伴有帮助。放心驱动移植的细节我可能写不到那么细但排查思路和原理是通用的。1. 先摸清T113内置Codec的家底再动手1.1 内置Codec和外挂Codec的开发方式差在哪全志T113内置的Audio Codec本质上是把DAC、ADC、耳机功放、LINE IN/OUT、MIC偏置这些模拟前端电路全部集成进SoC内部。和外挂Codec相比有几个直接影响开发方式的关键差异理解了这几个差异后面调起来会顺很多。第一寄存器访问方式完全不同。外挂Codec通常挂在I2C总线上驱动通过I2C读写寄存器调试时也可以用i2c-tools手动改寄存器验证硬件。内置Codec的寄存器直接映射在SoC内部总线地址空间里驱动是ioremap加readl/writel直接操作没有I2C时序可言。这带来一个很实际的问题在驱动加载之前你想手动验证Codec是否工作基本不可能必须依赖内核驱动先把基础初始化做完。第二数字侧接口形态不同。外挂Codec的数字接口是I2S/TDM引脚和SoC的I2S控制器通过PCB走线相连。T113的内置Codec数字侧不和外部引脚打交道但它也不会凭空拿到数据音频数据依然要经过SoC内部的I2S/DAIFIFO模块搬运。所以你会看到T113的设备树里有codec节点也有i2s节点还有一个把两者绑定在一起的sound节点三个节点缺一不可。简单理解I2S控制器负责把DDR里的音频数据搬进FIFOCodec负责把数字信号变成模拟信号。第三可参考的数据手册厚度不同。外部Codec的手册动不动几百页寄存器描述详尽内置Codec能拿到的寄存器手册往往是简版甚至只能看驱动源码反推。这就决定了在T113上调音频很大一部分工作不是写驱动而是学会通过ALSA导出的控件去配置音频通路用tinymix、amixer这类工具做“软件接跳线”。这个思维不转过来后面会一直在驱动代码里绕圈。1.2 播放和录音两条链路先搞清楚动手配置之前必须先对T113内置Codec的音频通路有个宏观认识。拿播放来说整条链路是这样的DDR里的PCM数据 - DMA搬运 - I2S/DAIFIFO - Codec数字侧 - DAC - 模拟开关/音量 - HPL/HPR输出脚 - 耳机或后级功放录音链路则刚好反过来MIC输入 - MICBIAS提供偏置 - PGA放大 - ADC - 数字滤波 - I2S/DAIFIFO - DMA - DDR这两个链路上最容易忽略的是“通路”这个概念。Codec内部不是一条固定的输入到输出直通线路而是有一堆模拟开关和混音器默认情况下这些开关基本都是关闭的。就算驱动加载成功、ALSA也能看到设备你依然听不到声音因为在ALSA控件层面把通路打开之前Codec几乎处于全静音状态。这一点和外挂Codec上电默认就有输出通路的行为很不一样也是新手遇到的第一道坎。我习惯用自来水管来理解这个过程PCM数据是水DMA是水泵DAC/ADC是水厂音频通路是水管那些ALSA控件就是水管上的阀门。出厂状态下所有阀门都是关的你要根据实际使用场景决定开哪些阀门。播放音乐就开DAC到耳机的阀录音就开MIC到ADC的阀同时做对讲就要两边都开。1.3 内核配置与BSP准备在动手配置设备树之前先确认内核的音频相关配置已经打开。全志的Linux SDK里内置Codec驱动通常在sound/soc/sunxi/目录下配置项名称不同SDK版本略有差异但一般会包含以下几类内置Codec驱动本身配置项类似CONFIG_SND_SOC_SUNXI_CODECI2S/DAIFIFO控制器驱动类似CONFIG_SND_SOC_SUNXI_I2SMachine驱动或simple-audio-card支持CONFIG_SND_SIMPLE_CARDALSA底层支持CONFIG_SND_ALSA相关的默认配置在这些配置打开并编译通过之后建议先把buildroot或根文件系统里的调试工具集备齐。桌面Linux上我们习惯用aplay、arecord、amixer这些属于alsa-utils。嵌入式环境下更常见的是tinymix、tinyplay、tinycap这一套tinyalsa工具体积小交叉编译方便调试嵌入式音频基本够用。buildroot里对应的是tinyalsa相关package直接勾选编译即可。我见过太多人在这步就卡住内核配置不对直接导致设备树配了也没反应probe报错或者声卡根本没创建。所以先把配置项一个一个确认好再往下走。2. 设备树里的Codec节点每一行配置都有讲究2.1 ASoC三大组件在T113上的对应关系Linux音频驱动基于ASoC框架这个框架把音频系统拆成三个角色machine、platform、codec。理解这三个角色在T113上怎么对应设备树就不会配错。machine负责描述“我这款板子上的音频电路长什么样”包括音频通路怎么接、声卡叫什么名字。T113上一般由sound节点承担很多SDK直接用simple-audio-card或者全志自定义的machine驱动来实现。platform负责数字侧的数据搬运T113上对应的是I2S/DAIFIFO控制器节点承担DMA传输和I2S时序生成。codec负责模拟侧的编解码T113上对应内置Codec节点包含DAC、ADC、混音器、音量控制等模拟部件。设备树里的绑定关系是通过sound-dai属性串联的。sound节点里的cpu子节点指向i2s节点codec子节点指向codec节点这样内核就知道“这个声卡的数字侧用哪个I2S控制器模拟侧用哪个Codec驱动”。三者缺任何一个声卡都无法正常工作。2.2 一次完整的Codec设备树配置解读下面是一份典型的T113音频相关设备树配置地址和时钟部分以你拿到的SDK实际dtsi为准但结构基本就是这个样子/* 内置Codec节点 */ codec: codec01c22c00 { #sound-dai-cells 0; compatible allwinner,sun8i-t113-codec; reg 0x01c22c00 0x400; clocks ccu CLK_BUS_CODEC, ccu CLK_CODEC; clock-names bus, codec; resets ccu RST_BUS_CODEC; status okay; }; /* I2S/DAIFIFO控制器节点 */ i2s0: i2s001c22400 { compatible allwinner,sun8i-t113-i2s; reg 0x01c22400 0x400; clocks ccu CLK_I2S0; clock-names mod; resets ccu RST_I2S0; dmas dma 3, dma 3; dma-names rx, tx; status okay; }; /* 声卡绑定节点 */ sound { compatible simple-audio-card; simple-audio-card,name t113-audio; simple-audio-card,format i2s; simple-audio-card,mclk-fs 256; simple-audio-card,bitclock-master sndcodec; simple-audio-card,frame-master sndcodec; sndcpu: simple-audio-card,cpu { sound-dai i2s0; }; sndcodec: simple-audio-card,codec { sound-dai codec; }; };逐行解释一下关键属性。#sound-dai-cells必须设为0表示这个节点作为DAL时不需要额外参数这是simple-audio-card引用的前提。compatible要和驱动里的of_match_table对应不能自己想当然写驱动不认就probe失败。clocks这里配了两路时钟一路是总线时钟访问寄存器靠它另一路是Codec模块时钟DAC/ADC工作要靠它缺一个都会导致异常。reset属性对应复位控制全志平台基本都要配。mclk-fs 256的意思是MCLK频率是采样率的256倍44.1kHz采样率下MCLK就是11.2896MHz。这个值不是随便写的要看Codec内部锁相环和数字滤波器的要求具体支持哪些倍率和驱动源码里的约束一致才行。配完设备树之后重新编译内核和dtb烧录时很多人会忘记dtb放在独立的boot分区。改了dts但没更新dtb这种低级问题我浪费过整整半天检查顺序永远是先确认dtb真的烧进去了。2.3 怎样确认Codec驱动有没有成功probe设备树配完之后第一件事不是急着测试音频而是确认驱动有没有正常加载。以下几步可以快速判断# 查看内核日志中audio相关输出 dmesg | grep -iE codec|asoc|snd # 查看系统识别到的声卡 cat /proc/asound/cards # 查看声卡下的PCM设备节点 ls -l /proc/asound/如果一切正常/proc/asound/cards里会出现类似这样的输出0 [t113audio ]: t113-audio - t113-audio t113-audio/proc/asound/下面会出现controlC0、pcmC0D0c、pcmC0D0p等条目。pcmC0D0c代表声卡0设备0的capture录音通道pcmC0D0p代表playback播放通道。看到这些说明Codec驱动和I2S驱动都已经成功probe了。如果声卡没有出现排查顺序一般是先看dmesg里有没有codec节点匹配失败再看sound节点有没有报错最后确认simple-audio-card有没有正确绑定。最常见的原因是compatible名字对不上或者某个时钟/reset属性没有被内核解析成功。3. 用ALSA控件和命令行工具把通路打通3.1 先备齐调试工具设备树配好、声卡出现之后真正折磨人的阶段才开始。这个阶段的核心工具不是示波器而是ALSA控件操作命令。桌面Linux下用amixer直接控制控件aplay/arecord做播放录音。嵌入式环境里建议直接用tinyalsa那套工具命令格式更简洁全志SDK里一般也默认带了tinymix查看和设置Audio Codec的各个控件相当于嵌入式版amixertinyplay播放WAV文件tinycap录制PCM数据到文件tinyhost查看PCM设备属性首次拿到板子先执行tinymix不带任何参数把Codec驱动导出的所有控件列出来。这一步非常关键不同SDK版本导出的控件名差异很大有的叫DACL Volume有的叫DAC Volume有的叫Audio Control这些名字直接决定你后续配置通路的写法。我拿到新板子第一件事永远是跑一下tinymix把它输出保存下来和Codec驱动源码里的snd_kcontrol_new定义对照看一遍心里就有数了。3.2 播放通路控件配置实例假设你的板子耳机接的是HPL/HPR输出播放一个WAV文件的完整操作如下# 先看所有控件当前状态 tinymix # 打开DAC使能 tinymix DAC Enable 1 # 打开耳机功放使能 tinymix HP Enable 1 # 设置DAC音量具体范围看tinymix输出里的min/max值 tinymix DAC Volume 157 # 设置耳机音量 tinymix HP Volume 120 # 播放WAV文件-D指定声卡设备号-d指定PCM设备号 tinyplay /tmp/test.wav -D 0 -d 0这里有几个容易被忽略的细节。音量控件的数值范围不是0到255这种固定值而是由驱动里定义的soc_mixer_control决定的有的范围是0到63有的0到255。tinymix输出里会直接显示当前值和范围比如DAC Volume 157 (range 0-255)照着范围设就行。通路开关的顺序有讲究。先使能DAC数字侧等DAC稳定之后再打开耳机功放模拟侧这样可以避免功放开关瞬间的直流冲击直接灌到耳机。关闭的时候反过来先关耳机功放再关DAC。单纯为了测试功能可能感受不到差别但后面做产品、整机测试的时候这个顺序直接决定有没有开关机爆音。3.3 录音通路的配置实例录音通路配置比播放稍微复杂一点因为牵扯到MIC偏置和增益。# 使能MIC输入通道 tinymix MIC1 Enable 1 # 设置PGA增益一般从0dB开始试 tinymix MIC1 Gain 0 # 使能ADC tinymix ADC Enable 1 # 设置ADC音量 tinymix ADC Volume 160 # 录音5秒钟双声道16bit16kHz采样率 tinycap /tmp/test.wav -D 0 -d 0 -c 2 -r 16000 -b 16 -T 5录完之后用tinyplay回放能听到刚才录进去的声音就说明录音链路基本通了。但这里有个非常关键的验证步骤被很多人跳过录音之前先用示波器或者万用表量一下MIC输入引脚确认MICBIAS偏置电压有没有出来。驻极体麦克风必须靠偏置电压才能工作如果偏置没输出后面配置什么都是白搭。T113内置Codec的MICBIAS一般在1.8V到2.2V之间不同平台有差异以手册为准。另外要确认硬件是差分输入还是单端输入。如果板子上MIC接的是单端方式软件就要把输入配置成单端如果接的是差分方式软件要对应打开差分模式。这个配置经常在Codec驱动里作为一个控件存在或者在设备树的routing里体现。配错的结果就是录音能录到信号但信噪比惨不忍睹。3.4 用示波器和波形文件验证功能很多工程师觉得能用tinyplay把WAV放出来就算调通了其实那只是第一步。我测试时有个固定流程播放侧我用软件生成一个1kHz正弦波的WAV文件然后让板子持续播放用示波器探头接HPL/HPR输出脚。1kHz正弦波在示波器上看起来是干净的正弦曲线如果有削顶、畸变、直流偏置异常一眼就能看出来。没有示波器的话把音量从小往大调用耳机听也能发现失真临界点。录音侧录完的WAV文件一定要拉回电脑用Audacity之类工具看波形。不是听一下“有没有声音”就完事要看底噪幅度、信号幅度、有没有周期性杂波。如果信号幅度只有40mV而底噪就有20mV这个录音质量根本没法用后面再去排查是EMI还是增益配比问题。4. 调音路上必踩的几个坑现象、根因与排查链路4.1 录出来的全是刺啦噪音MIC偏置与增益的相互配合这是我在T113平台上遇到最多的问题现象很统一录音文件里有声音但背景一直有明显的高频“沙沙”声或者低频哼声。完整的排查链路应该是这样的先看录音文件里的有效信号。如果播放录音能听到清晰的语音或测试音说明从MIC到ADC的物理链路没问题问题出在增益配比或者偏置上。然后用tinymix查PGA增益。很多工程师习惯把增益调高来弥补MIC灵敏度不足结果环境底噪被同步放大。PGA增益每提高6dB底噪电压翻一倍信号和底噪的比值并不会因为提高增益而变好。正确的做法是把PGA增益放在足够识别信号的最低档位后续如果还需要放大优先在数字域处理。接着量MICBIAS。偏置电压异常偏低时驻极体MIC的工作点不对输出信号会严重失真伴噪音。还有MIC输入脚和地线之间的耦合问题如果PCB上MIC走线和电源走线平行太长录进去的全是电源噪声。最后是接地问题。模拟地和数字地单点连接是基本要求如果是两层板MIC地回路被数字信号污染录出来的波形会明显叠加周期性毛刺。这个问题软件没法完全消除只能改板但可以用低通滤波缓解。4.2 播放无声或者只有一边响别急着怀疑驱动播放时tinyplay进度条正常走但耳机里没声音或者只有左声道有声音这大概是T113音频调试里最常见的第二个坑。先按顺序自查第一查HPD耳机插入检测。很多开发板或产品会把耳机座的检测脚接到Codec的HPD引脚上。如果HPD检测到“耳机未插入”驱动会自动把通路切到外放而外放后面根本没有接功放表现就是“完全没声音”。这个坑特别隐蔽因为你在tinymix里看到的控件状态可能完全正常。处理方式是在设备树里把HPD引脚配置成正确状态或者干脆在dts里禁掉HPD功能。第二查音量和使能控件。左右声道的Enable和Volume是独立的有的驱动里叫HP_L Enable、HP_R Enable有的叫HPL Volume、HPR Volume。如果软件只开了左声道耳机里自然只有左边响。这属于配置遗漏不是驱动bug。第三用示波器量HPL和HPR两个引脚。如果两个引脚都有信号波形但耳机只有一边响问题在耳机座或硬件线路如果其中一个引脚完全没有波形再回头看软件配置。4.3 录音和播放切换时出现“噗”的爆音这个问题的本质是模拟开关切换瞬间通路上直流电平突变耦合到耳机或喇叭后形成冲击声。T113这种内置Codec也不能幸免尤其是录音和播放切换比较频繁的产品形态比如对讲机、智能音箱。软件上的解决思路是控制开关顺序。打开录音通路时先使能ADC和PGA最后再打开MIC通路关的时候反着来。播放侧同理先开DAC再开功放。顺序对了爆音能减轻很多。更彻底的做法是利用ASoC的DAPM机制。在驱动里把功放widget和DAC widget的依赖关系配好让内核自动管理上下电顺序。前提是设备树里simple-audio-card的widgets和routing配置要和Codec驱动源码里的DAPM定义一致这个一致性很多人配不对最后干脆回流到用户态手动控顺序。4.4 音量参数和失真的关系调试音量时有一个很容易混淆的点数字音量和模拟音量的区别。DAC Volume是数字域的调的是PCM样本放大倍数HP Volume是模拟域的调的是模拟输出级增益。两者一起调高了信号很容易在某一级被削波。判断是否削波有个简单标准播放1kHz正弦波音量从小到大拧同时用示波器看输出波形。当波形顶部和底部出现平顶时就是削波了。此时要让音量退回几个dB。如果产品需要更大声优先提高后级功放增益和电源电压而不是硬拉Codec音量。顺便提一句开机的瞬间如果DAC还没稳定就把音量拉满也会出现短暂爆音。产品量产前这类细节都要处理好否则客户拿到手第一个抱怨就是“开机砰一声”。下面用表格把几个高频问题汇总一下问题现象可能原因排查步骤录音噪声大MICBIAS异常、PGA增益过高、地线设计差量偏置电压调整增益检查PCB接地播放无声HPD误判、通路未开、功放无使能查tinymix控件状态量HPL/HPR输出单声道左右声道使能或音量配置漏项分别确认左右声道控件开关机爆音模拟开关时序不对先开DAC再开功放关闭时逆序音量一高就破音数字音量或模拟音量削波示波器看波形保持6dB余量5. 采样率、位深与时钟树的匹配逻辑5.1 T113上常用的音频参数组合T113内置Codec支持的采样率覆盖很广从8kHz到192kHz都有但日常产品里用的最多的就几组44.1kHz/16bit/双声道传统CD音质音乐播放场景48kHz/16bit/双声道多媒体的通用格式视频、VoIP、录音基本都是这个48kHz/24bit/双声道需要更高动态范围的录音场景16kHz/16bit/单声道语音识别、对讲机场景录音和播放的采样率最好保持一致。如果一边是44.1kHz一边是48kHz除非软件做重采样否则音频数据会变调或者出现周期性卡顿。5.2 时钟链和采样率的关系理解BCLK和LRCK很多人在T113上遇到过音调不对的问题听起来像磁带快进这就是时钟频率配置错误导致的。要理解这个问题得先理清Codec的时钟链。音频主时钟MCLK通常由SoC的PLL分频产生经过Codec内部锁相环或分频器后生成位时钟BCLK和帧时钟LRCK。三者关系满足LRCK 采样率fs它决定左右声道切换频率BCLK fs × 声道数 × 位深它决定每一位数据的时钟MCLK通常是fs的整数倍常见256fs、512fs举个例子48kHz采样率、双声道、16bit配置下LRCK频率就是48kHzBCLK 48000 × 2 × 16 1.536MHz如果系统MCLK配的256fs就是12.288MHz调试时用示波器量I2S引脚或者Codec内部时钟测试点BCLK和LRCK频率只要有一项不对声音必然异常。改采样率后建议重新量一遍因为有些驱动对时钟分频的配置是静态的切换采样率后没有动态更新。设备树里simple-audio-card,mclk-fs这个值会直接影响MCLK频率。有的Codec要求256fs有的支持512fs配错的结果可能是驱动拒绝打开PCM设备或者出声但音调不对。5.3 16bit和24bit在位深切换时容易踩的坑位深配置错误不太容易直接发现因为系统通常能出声只是声音质量异常或者有噪声。T113的I2S控制器和DMA在搬运数据时对16bit和24bit的处理方式不同。24bit数据在DMA buffer里通常是右对齐存放在32bit容器中也就是低24位有效高8位补零。如果应用层写的是16bit数据而驱动配置成了24bit格式播放时DAC会把这16bit数据当作24bit读取结果声音严重失真听起来像噪声杂糅在一起。排查方法很简单用tinyplay播一个标准WAV分别用-b 16和-b 24参数试看哪个是正常声音哪个是杂音。正常的那个位深就是当前驱动配置匹配的格式。另外要注意嵌入式系统里ALSA库默认可能没有启用格式转换插件。如果应用以44.1kHz/16bit打开PCM设备而驱动只支持48kHz/24bit标准桌面Linux会自动做重采样和格式转换但裁剪过的嵌入式系统往往编译时去掉了这些插件结果是打开设备直接报错。所以应用层代码里尽量使用和驱动默认配置一致的参数避免依赖ALSA插件层。6. 从Codec到整机外接功放、开关机爆音与低功耗落地6.1 外接喇叭功放时的硬件和软件协同T113内置Codec的HPL/HPR输出直接推耳机没问题但要驱动几瓦的喇叭必须外接功放PA常见的有PAM8403、TPA3116这类D类功放。外接PA有几点要特别注意。首先T113的DAC输出通常带直流偏置PCB设计时HPL/HPR到PA输入之间要加隔直电容一般10uF到47uF否则直流分量会直接进入PA轻则影响音质重则损坏喇叭。其次PA的使能脚EN或Shutdown时序必须在软件上严格处理。正确顺序是先让Codec的DAC和模拟输出建立稳定的信号再拉高PA使能脚让音频通路里已经是平稳信号之后才切到喇叭。反过来关机时先拉低PA使能再关Codec。这个时序在Linux下一般通过GPIO控制PA的使能引脚可以由用户态应用在播放前后操作也可以在设备树里配置成ALSA DAPM事件回调自动控制。最后是增益配比。PA本身有固定增益比如20dB、26dBCodec输出幅度不能太大否则PA前级就削波了。我的经验值是Codec输出幅度预留6dB headroom也就是正弦波峰值不超过PA最大输入的三分之二这样动态大的音乐不会突然破音。6.2 多声卡同时存在时的策略T113板子上不一定只有内置Codec这一个声卡很多产品同时接了USB声卡、HDMI音频或者蓝牙音频。这时/proc/asound/cards会列出多个声卡编号可能是变化的应用层如果写死编号就会出问题。编译ALSA库的嵌入式系统可以通过/etc/asound.conf指定默认声卡比如defaults.pcm.card 0 defaults.ctl.card 0但更稳妥的做法是在应用层显式指定声卡和设备而不是依赖系统默认值。tinyplay这类工具就支持-D 0 -d 0参数显式指定。还要注意多声卡并发时的DMA资源。T113的DMA通道是有限的内置Codec录音、播放、USB声卡同时工作时要确认DMA通道没有冲突。以我的经验如果驱动在probe时已经把DMA通道申请好了同时使用问题不大但如果某个声卡驱动写得不规范DMA通道复用时会出现诡异的数据错乱比如录音数据里混着播放数据这个方向可以查。6.3 低功耗场景下的Codec电源管理电池供电的产品对功耗敏感Codec这部分不能忽略。T113内置Codec在待机时如果还保持DAC、ADC全上电电流消耗会明显偏高。ASoC框架的DAPM机制会根据音频流的状态自动管理Codec内部电源。播放或录音时自动打开相关部件空闲时自动关闭。但这个自动管理要生效前提是驱动里DAPM widget定义完整设备树里routing配置正确。如果某个widget没有挂到DAPM图里它就会被当作“常开”部件一直耗电。手动验证低功耗是否生效可以播放一首歌然后停止用万用表量Codec供电电流看停止后电流有没有回落到空闲值。没有回落的话检查是不是某个通路没有关或者DAC还处于上电状态。还有总线时钟和复位的控制。设备树里CLK_BUS_CODEC和复位属性配好之后驱动在runtime PM框架下可以在音频空闲时关闭总线时钟、拉复位进一步降低功耗。全志的一些BSP内核里默认没有开启Codec的runtime PM需要自己确认驱动代码里有没有对应的pm_runtime_put_sync调用。最后再分享几条实战经验这些年在T113以及类似全志内置Codec平台上折腾我自己沉淀了几条原则供参考。第一永远按“物理信号 - 数字侧 - 软件配置”的顺序排查。示波器是嵌入式音频调试最可信的工具。软件配置可能出错控件名可能看花眼但模拟引脚的波形不会骗人。先确认DAC引脚有信号再回头查ALSA控件配置先确认MIC引脚有偏置电压和音频信号再怀疑ADC和DMA问题。这个顺序能替你省掉大量无效排查时间。第二每次改完设备树先确认dtb真的烧进板子再开始调。检查方式很简单板上启动后执行ls /sys/firmware/devicetree/base/看Codec节点属性和你预期的是不是一致。这个“低级问题”拖过我好几个半天后来学乖了。第三量产之前一定要花时间处理开关机爆音和音量削波。功能调试阶段能被听到的“砰”声、破音到了客户手里会被放大成产品缺陷。把DAPM配置和开关时序做对才是完整意义上的Codec调通。T113内置Codec的调试过程本质上是和ASoC框架打交道的过程。把设备树三节点关系、ALSA控件通路、时钟参数计算搞明白不光T113以后换到其他内置Codec的全志平台或者别家SoC思路都是一样的。祝大家少走弯路一次调通。