上一块全志 T527 的开发板在我工位上躺了两天前面十几个 BSP 任务刚清完这一轮终于轮到了 Audio。做 BSP 的老哥都懂全志 T527 这颗料在 AIoT、商显、边缘网关里出镜率很高八核 A55音频资源也算丰富但真正拿到一块板子时问题往往不是“有没有音频”而是“明明有音频接口怎么就出不了声”。有直接内建 Codec 的有外挂 I2S Codec 的还有带 DMIC、SPDIF、HDMI 音频混合需求的板级形态差了十万八千里。这篇文章不打算复述英文手册也不准备把 ALSA 那套机制从头讲一遍而是按 BSP 调试的真实顺序来先拆音频链路再核对内核配置和设备树然后从启动日志和声卡节点确认驱动状态最后按“无声、杂音、录音异常”几个典型症状做分诊。文末会补几个团队反复踩过、也花过不少时间才定位的坑。如果你正被 T527 或其他全志平台的音频问题搞得头大这篇应该能帮你省下大半天。实测环境是 Tina Linux 配合 5.15 左右版本的内核Android 侧的逻辑基本一致主要差异在 HAL 层和服务进程管理我会在对应位置单独说明。1. 音频调试前先摸清数据链路别急着改驱动1.1 音频链路拆成四段问题就不会跨段乱窜每次拿到新的音频需求我都会先把链路切成四段来看第一段是内存里的 PCM 数据由 DMA 控制器负责搬运第二段是数字接口常见的就是 I2S 或者 DMIC/SPDIF负责把数据按帧格式送到 Codec第三段是 Codec 本身完成 DAC/ADC 转换、混音、音量调节第四段是功放和喇叭或者麦克风输入侧的偏置电路。这个分法听起来基础但实际调试时特别有用。很多人一看到“没声音”就怀疑 Codec 驱动结果查了半天发现是功放的 GPIO 压根没拉起来或者用户空间的混音器通路是关的。用生活化的比喻来说DMA 是快递员I2S 是马路Codec 是翻译官功放和喇叭是会议室的音响。快递员把文件送到了马路也通畅翻译官也上线了结果音响没插电会议照样没声音。BSP 调试第一步就是先确认是哪一段断了电。我习惯把问题分成三类数字侧能否传数据Codec 模拟侧是否完成转换板级电源和 GPIO 是否给到位。只要问题落在哪一类对应的排查工具就完全不同这也是后面几章的展开逻辑。1.2 T527 上到底有哪些音频资源别上来就堆节点T527 这套 SoC 的音频资源大致有这几类内建模拟 Codec支持立体声 DAC 和 ADC适合直接驱动耳机、LINE OUT也能接麦克风数字音频接口 I2S0 到 I2S3可以外接更高性能的 CodecDMIC 接口适配远场语音和麦克风阵列SPDIF 接口用于数字音频输出另外还有 HDMI 音频走的是显示驱动那边的通路。很多开发板会在设计上做减法内建 Codec 输出直接连到耳机和 LINE OUT外接一颗 PA 功放驱动喇叭另留一组 I2S 给外部扩展 Codec。调试之前一定要先看原理图而不是拿参考设计整套设备树往上堆。堆节点的坏处在于多个 DAI 同时使能时钟和 GPIO 会互相抢占反而把最简单的通路搞复杂。选好通路之后在设备树里就只需要关心对应那几个节点Codec 节点、I2S 控制器节点、声卡顶层节点。我在调试中见过有人在 DMIC 和 I2S 两个方案之间反复横跳其实就是没有先确认硬件原理图上到底走了哪组 PIN。音频调试最忌讳“猜”一个万用表能解决的事千万别靠日志去反推。2. 内核配置与设备树核对先“能出声”再谈效果2.1 内核里少了 SND_SOC 选项设备树写得再对也没用有一类问题特别低级但特别常见设备树加了一堆节点声卡就是不出来最后发现内核根本没编译音频框架。T527 的 BSP 内核通常会带全志自己的 ASoC 驱动但不同 SDK 裁剪程度不同尤其是做产品精简的时候容易把音频相关的 CONFIG 项裁掉。建议先在内核运行环境下确认zcat /proc/config.gz | grep -E CONFIG_SND_SOC|CONFIG_SND_SIMPLE_CARD|CONFIG_SND_AOA如果没有/proc/config.gz说明内核没开 CONFIG_IKCONFIG那就直接查编译内核时的.config文件。常用的几个配置项包括CONFIG_SND_SOC_SUNXI全志 ASoC 驱动框架、CONFIG_SND_SIMPLE_CARDsimple-audio-card 驱动、CONFIG_SND_SOC_DMIC数字麦克风、CONFIG_SND_SOC_SPDIFSPDIF 驱动。如果是外挂 Codec还需要对应的 Codec 驱动配置项比如CONFIG_SND_SOC_NAU88C22或CONFIG_SND_SOC_ES8388。我遇到过这种情况aplay -l看不到声卡dmesg里也没有任何 ASoC 报错感觉像驱动没加载。后来把内核配置一翻发现相关驱动编译成了模块模块又没打包进 rootfs。所以在检查设备树之前花三分钟确认配置项是值得的。控制变量一次只动一个地方。2.2 设备树里的三个节点缺一不可T527 上用 simple-audio-card 作为声卡模型时设备树里必须有三个角色Codec 节点、DAI 控制器节点、声卡顶层节点。三者通过sound-dai属性串联起来缺一个声卡都注册不上。下面是一份常见的 T527 音频设备树片段模拟 Codec 加 I2S0 的接线方式i2s0 { status okay; pinctrl-names default; pinctrl-0 i2s0_pins; }; codec { status okay; #sound-dai-cells 0; }; sound_t527 { compatible simple-audio-card; simple-audio-card,name t527-snd; simple-audio-card,format i2s; simple-audio-card,mclk-fs 256; simple-audio-card,bitclock-master cpu_dai; simple-audio-card,frame-master cpu_dai; cpu_dai: simple-audio-card,cpu { sound-dai i2s0; }; simple-audio-card,codec { sound-dai codec; }; };重点解释几个属性。format i2s表示标准 I2S 时序如果外接的是 DSP 模式 Codec需要改成dsp_a错了会表现为“有数据流但全是噪声”。mclk-fs 256表示 MCLK 频率是采样率的 256 倍比如 48kHz 采样率对应 12.288MHz MCLK。很多 Codec 对 MCLK 和 LRCK 的比例有明确要求查手册核对不能想当然。bitclock-master和frame-master要指明是 CPU 侧还是 Codec 侧做主两边都配成主机模式就会导致时钟冲突。codec节点是否使能、#sound-dai-cells是否为 0、status是否为 okay这三个是高频翻车点。每次改完设备树重新编译 boot.img 或 dtb确认实际生效别在旧 dtb 上反复怀疑人生。2.3 电源、功放使能和上电顺序是无声问题的高发区设备树节点和内核配置都对声卡也能注册但喇叭就是不响十有八九是电源或 GPIO 上电时序的问题。T527 的参考设计里内建 Codec 输出后通常会接一颗 D 类功放功放的使能脚由 GPIO 控制。这颗 GPIO 什么时候拉高、什么时候拉低直接决定了会不会有爆音或者完全无声。这颗 PA 使能脚常见的三种接法由 Codec 驱动直接控制对应设备树里类似allwinner,pa-gpios的属性由板级驱动控制在声卡注册时通过 DAPM 事件去拉由用户空间脚本控制开机后用 gpio 命令去设置。前两种比较正规第三种只适合快速验证量产产品不建议。调试时一定要先确认这颗 GPIO 的电平逻辑是高有效还是低有效。同一块底板可能有两种版本丝印一样但三极管方向相反。我吃过这个亏原理图上明明标着高电平使能实测要高电平关断结果连续调了三天“无声”。用万用表去量 PA 的 EN 脚电压比反复加打印日志要快得多。另外上电顺序也很重要。Codec 的 MCLK 和电源稳定之前PA 如果提前打开轻则爆音重则把喇叭振出杂音。正规做法是等 Codec 完成初始化、DAPM 通路建立后再使能 PA或者干脆用 DAPM 的SUPPLY机制去管理功放电源。3. 用启动日志和声卡节点确认驱动层到底干了什么3.1 dmesg 是第一个现场先别急着抓波形每次音频调试我第一件事不是拿仪器而是看dmesg。内核在声卡注册和 Codec 探测时会打印大量 ASoC 相关信息基本能把问题范围缩小到具体模块。dmesg | grep -iE asoc|codec|i2s|dmic|sound|snd | tail -n 100正常情况下能看到类似这样的关键行声卡和 DAI 完成映射比如t527-snd - i2s0 mapping okCodec 驱动成功探测比如codec 0-0011: ASoC: codec probe success。如果声卡没有注册这一条就不会出现或者伴随明确的错误。几个常见日志现象值得记住出现failed to instantiate card -517说明存在设备依赖未就绪通常是电源域、时钟或 Codec 还没 probe内核在重试这时候要检查相关节点的status和clocks出现i2c transfer error或codec: probe failed说明 Codec 所在的总线访问失败大概率是 I2C 地址错了或者线路问题完全没有任何 ASoC 打印说明内核配置或设备树根本没走到音频框架。除了日志还要关注/proc/asound下的内容。cat /proc/asound/cards能列出所有声卡cat /proc/asound/pcm能看到 PCM 设备节点。如果声卡出现了说明 ASoC 框架层面已经通了一半接下来才是用户空间工具的事。3.2 最小播放/录音测试矩阵永远用同一套命令声卡注册成功只是开始能不能播、能不能录需要一套稳定的命令来做最小验证。T527 的 BSP 环境可能同时存在 alsa-utils 和 tinyalsa 两套工具命令风格不同但底层访问的是同一个 ALSA 接口。我习惯建立这样一张对照表方便团队协作时统一口径工具常用命令适用场景注意点alsa-utilsaplay -l/arecord -D hw:0,0rootfs 比较完整时使用hw:0,0绕过插件层能暴露真实驱动问题tinyalsatinyplay /tmp/tone.wav/tinycap /tmp/cap.wav精简 rootfs、Androidtinyalsa 不读 alsa.conf环境变量影响小tinymixtinymix -D 0查看和设置控制项各版本参数略有差异批量设置前先 dump 当前值播放测试可以先合成一段单频正弦波比如 997Hz、48kHz、双声道音量控制在 30% 左右避免满幅信号把功放推爆。播放时用aplay -D hw:0,0如果失败再试plughw:0,0。hw失败通常代表驱动或格式有问题hw成功但plughw失败才需要查用户空间配置。录音测试可以用arecord -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 3 /tmp/cap.wav。加-vvv参数可以看到录音过程中的电平变化这一招很实用能快速区分“完全没信号”和“信号弱”两种情况。3.3 自录自放形成回环快速定位 DAC 还是 ADC 出问题当播放和录音分别测都失败时可以用回环法定位故障侧。很多 Codec 具备模拟或数字回环功能通过tinymix把 DAC 输出接到 ADC 输入然后播放一段音频同时录音最后比对录音文件。如果板上预留了 Line In 和 Line Out 的 3.5mm 插孔直接用一根对录线把二者短接是最原始的模拟回环。没有对录线时也可以把喇叭输出贴近麦克风录但这种方式引入的环境噪声太大只能做定性判断不适合定量分析。录音完成后用 sox 或 python 查看录音文件的峰值和 RMS 电平sox /tmp/cap.wav -n stats 21 | grep -E Max level|RMS lev如果回环录音电平接近 0说明回环路径本身就有断路如果电平正常但外部播放没声音问题反而集中在功放和喇叭侧。这种分割方式能避免在一个问题上反复打转。还有个小技巧播放文件不要用常见音乐因为音乐本身有静音段很容易误判成没声。用单频正弦波加少量噪声或者扫描信号观察录音频谱就一目了然。4. 无声、杂音、录音异常实战分诊顺序才是关键4.1 声卡没有注册出来多半是 I2C 或 DAI 探测失败声卡没注册是最容易排查但信息量最大的问题。先在/proc/asound/cards里确认是不是真空再用aplay -l看 PCM 设备。两者都为空时从dmesg里找 ASoC 错误。如果是外挂 Codec需要用 I2C 工具确认 Codec 芯片是否真的在总线上。T527 的 I2C 控制器编号不一定和原理图上的编号一致先用i2cdetect -l列出总线再用 i2cdetect 扫描i2cdetect -y -r 0 i2cdetect -y -r 1扫描结果里出现UU或具体地址时表示有设备响应。如果全总线都扫不到先量 I2C 的上拉电阻和 SCL/SDA 电压别急着改驱动。如果地址和原理图对不上也要仔细核对 Codec 芯片的地址引脚配置很多 Codec 有多个可选地址地址错了驱动当然 probe 不到。failed to instantiate card -517值得单独说。-517对应-EPROBE_DEFER表示这次没成功是因为依赖还没准备好内核后面会重试。这种问题要去看 Codec 的时钟、电源域和 GPIO 控制器是否都先于声卡 probe顺序不对就会一直 defer 直到超时。强制去掉某段依赖看看现象往往比盯着日志猜更快。4.2 有声卡但不出声从软件通路和功放 GPIO 两头夹击“声卡正常、播放命令也返回成功、耳机喇叭就是没动静”是我在音频排障里遇到最多的组合。这时候我先怀疑混音器通路再怀疑功放 GPIO。用户空间看到声卡不代表 ASoC 的 DAPM 通路已经连通。先用tinymix -D 0把全部控制项打出来重点看播放路径相关的开关和音量项。不同 Codec 命名差异很大但通常有这几类DAC 侧开关决定数字信号是否进入模拟输出耳机或喇叭通路开关决定模拟输出是否送到对应引脚主音量或左右声道音量。很多 Codec 出厂默认把输出通路设为关闭开机时不会自动打开这很常见。确认软件通路之后再看 PA 使能。用 debugfs 查 GPIO 状态cat /sys/kernel/debug/gpio | grep -i pa如果 GPIO 没有按预期拉高或拉低就用示波器或万用表在 PA 芯片的 EN 引脚上量电位。之前我遇到过一种情况GPIO 配置在设备树里没问题但被其他驱动抢先 claim导致功放使能失效。这时候在相关驱动里加gpio_request和gpio_set_value的日志很容易看出是哪一段在互相抢资源。有个经验是不要一上来就怀疑 Codec 寄存器。Codec 寄存器读写异常会直接在 I2C 通信上暴露出来而“通路是关的”这种状态不会报错只有通过 mixer 控制项才能发现。先把控制项全部开启再试播放不行再往硬件侧查。4.3 播放有杂音、爆音和偏音先怀疑时序再怀疑寄存器如果声音能出来但伴随明显杂音、爆音或左右声道不平衡调试思路要比“完全无声”更深一层。杂音问题第一怀疑对象是 MCLK 和 BCLK 的比例。Codec 手册通常规定了支持的主时钟频率范围比如 256fs、384fs、512fs。如果设备树里没有正确设置mclk-fsCodec 内部锁相环可能工作在不理想状态表现出来就是采样率跳动或者持续性噪声。计算方式很简单采样率 48kHz 时256fs 就是 12.288MHz。如果内核里实际输出的 MCLK 是 11.2896MHz那对应的是 44.1kHz 采样率的 256fs放 48kHz 音频时必然出问题。查/sys/kernel/debug/clk/clk_summary里对应时钟的实际频率比反复修改配置更快。爆音则更多来自上电时序。功放在 Codec 输出还没有稳定时就开启或者 Codec 初始化过程中某路电源先于模拟基准电压到达都会产生 POP 声。解决办法是在驱动里给 PA 使能增加延时或者把使能过程挂到 ASoC DAPM 的SUPPLY事件上让内核在建立播放通路时自动完成时序控制。爆音问题只靠改用户空间脚本很难根治最好在驱动层解决。左右声道不平衡先用单声道文件分别播放左右声道确认是信号源问题还是硬件问题。播放997Hz的单声道左声道文件如果右声道也有声音说明通路有串扰或 mixer 没配好。硬件侧还要看 PA 的左右输入电容有无虚焊。软件侧则重点查tinymix里左右声道的音量控制项是否被单独设置过。这类问题通常不是器件本身坏了而是控制和硬件之间有盲区。4.4 录音采不到音或者音量极小MIC 通路参数要对号入座录音问题比播放问题更隐蔽因为用户往往说不清楚“是没声音”还是“声音太小”。先统一用arecord -vvv录音并观察峰值如果峰值一直为零说明模拟信号根本没进 ADC如果峰值有一点但很低说明增益不够或偏置没配好。麦克风需要偏置电压才能工作这是常见盲区。T527 内建 Codec 的 MICBIAS 引脚要供电否则驻极体麦克风完全没有输出。外部数字麦克风则可能需要独立供电引脚例如 DMIC 的VDDMIC同时还要配置DMIC CLK引脚对应的 GPIO 复用。检查设备树和tinymix中 MICBIAS 相关控制项如果软件侧已经使能再用万用表量 MIC 引脚上的直流电压是否在 1.8V 到 2.8V 左右这个电压能快速判断供电是否到位。增益设置方面Codec 内部通常有两级可调增益ADC PGA 和输入混音器增益。默认值往往比较保守导致录音音量偏小。通过tinymix逐步提高输入增益同时录一段白噪声或人声来对比波形。注意增益别一次拉满太高容易饱和削波录出来的声音反而更难听。对于 DMIC 方案还要看 pinmux 是否正确。DMIC 的 CLK 和数据引脚如果被其他模块占用内核不会报错但信号就是进不来。用sunxi-pinctrl的 debugfs 接口检查引脚当前功能状态确认是否和设备树一致。调试时我还会用短语音加持续说话的方式录音避免环境静音造成“没录到”的误判。5. 复盘日志、自动脚本和能省时间的几个经验5.1 现场信息收集清单能少让人反复问就少问音频问题定位过程中最怕拿到的问题描述只有一句“没声音”。我现在要求团队在反馈问题时必须附上四件套完整dmesg音频相关日志、/proc/asound/cards和/proc/asound/pcm内容、tinymix -D 0的完整 dump、实际播放和录音命令及返回结果。可以写一个简单的收集脚本快速打包mkdir -p audio_log dmesg | grep -iE asoc|codec|i2s|dmic|sound|snd audio_log/dmesg_sound.log cat /proc/asound/cards audio_log/cards.txt cat /proc/asound/pcm audio_log/pcm.txt tinymix -D 0 audio_log/tinymix.txt 21 arecord -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 3 audio_log/cap.wav 21 | tee audio_log/record.log有了这些资料大多数问题不需要再反复远程试错直接看日志就能缩小到某个层面。如果录到了 wav 文件建议同时用 python 或 sox 算一下峰值电平作为附件一起提交。会看数据和不会看数据在音频调试中的效率差得不是一点半点。5.2 几个反复踩过的坑值得写进新人排查清单第一个坑是把 PA 使能当成普通 GPIO 处理。新版内核里如果 PA 使能逻辑不挂在 Codec 或声卡驱动里启动时可能因为 GPIO 初始状态不对导致功放在上电瞬间就打开爆音、杂音全来了。PA 使能位置选对了能省掉很多后续处理。第二个坑是设备树节点写了但status没改。T527 的 BSP 设备树里I2S、Codec、DMIC 节点默认可能是disabled只把status改成okay还不够还要确认对应的 pinctrl 没有被其他模块占用。有一类问题是用户空间用别的功能复用掉同一组引脚导致音频引脚功能不对现象极其诡异。第三个坑是混合器控制项默认状态不确定。不同 SDK 版本、不同 Codec 驱动混音器默认值都不一样。一堆人用了同一个 Codec但系统版本不同通路设置完全不同却拿同一套 tinymix 参数去套怎么调都调不对。遇到问题先tinymix -D 0dump 当前环境再对照 datasheet 判断开关和增益是否正确。还有一个比较有意思的场景嵌入式 Linux 里音频服务或守护进程启动失败时现象跟 PC 上“Windows Audio 服务起不来”很像。T527 跑 Android 时audioserver可能因为权限或 so 库加载失败反复重启表现为声卡节点正常但上层无法播放跑 Tina Linux 时pulseaudio 或 alsa-state 服务起不来也会让应用层报错。和 PC 端装个 Realtek Audio Console 就能解决的问题不同板子上这类问题要看服务日志、动态库依赖和 SeLinux 规则。把服务和驱动当成两回事能少走很多弯路。5.3 把验证过程脚本化避免每次重复手敲命令音频调试到最后一定会进入“反复验证”阶段。我习惯把所有步骤整理成一个 shell 脚本每次改完驱动或设备树以后直接跑一遍输出结果一目了然。下面这个脚本的思路是生成标准测试音频播放一遍再录音一遍最后把关键日志和电平信息汇总打印。#!/bin/sh # 音频快速验证脚本声卡索引按实际环境调整 TONE/tmp/tone997.wav CAP/tmp/cap.wav python3 - $TONE PY import wave, struct, math, sys sr, freq, dur 48000, 997, 2 with wave.open(sys.argv[1], w) as w: w.setnchannels(2) w.setsampwidth(2) w.setframerate(sr) frames [] for i in range(sr * dur): v int(32767 * 0.3 * math.sin(2 * math.pi * freq * i / sr)) frames.append(struct.pack(hh, v, v)) w.writeframes(b.join(frames)) PY echo playback aplay -D hw:0,0 $TONE 21 sleep 1 echo capture arecord -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 3 $CAP 21 echo stats if command -v sox /dev/null 21; then sox $CAP -n stats 21 | grep -E Max level|RMS lev else python3 - $CAP PY import wave, sys try: w wave.open(sys.argv[1], rb) n w.getnframes() data w.readframes(n) import array samples array.array(h, data) if not samples: print(no data) sys.exit(0) peak max(abs(s) for s in samples) print(peak:, peak) except Exception as e: print(stat error:, e) PY fi脚本里故意把录音峰值统计做成 sox 不可用时的 python 替代方案保证在精简 rootfs 里也能跑。这个脚本的价值不在于代码多复杂而在于每次验证都有可比较的输出方便判断改动前后音量、通路是否发生变化。把“玄学”变成“前后对比数据”才是快速收敛问题的办法。调试音频是个精细活但也不是完全没有套路。每次拿到新板子我现在都习惯先花十分钟梳理一遍链路再决定从哪一层入手。T527 这套平台的音频资料不算少可资料多不代表板子一定按参考设计走板级差异永远存在。设备树、内核配置、电源时序、混音器通路这几样东西只要耐心排总能定位到问题。希望这篇记录里的命令和思路能帮你在下一次音频调试时省下更多时间。