RK3568音频驱动实战：从I2S协议到ALSA框架的完整调试指南

1. 项目概览RK3568上的音频通路到底是怎么跑起来的先说结论在RK3568上做音频播放核心工作就是把三条链路打通——I2S硬件链路、ALSA软件框架、Codec芯片控制三者缺一不可。很多新手一上来就急着写设备树、调tinymix结果声音出不来卡了半天才发现是I2S的引脚复用被其他外设抢了或者Codec的供电没给上这种坑我踩过不止一次。RK3568是瑞芯微推出的四核Cortex-A55处理器音频这块它并没有把Codec集成在SoC内部而是通过I2S、PDM、SPDIF等数字音频接口外接一颗Codec芯片比如市面上常见的ES8316、 WM8960、TLV320AIC31xx等等。这意味着你不能像单片机那样直接往某个寄存器写PWM就能出声而是要经历“应用程序 → ALSA库 → 内核ALSA框架 → I2S控制器 → Codec → 喇叭/耳机”这样一条完整的数据通路。这篇博文面向的是这类读者手里有一块RK3568的开发板主线内核已经能跑起来想通过ALSA驱动实现音频播放但对I2S协议和设备树的配合关系还比较模糊需要一份能直接照着操作、同时把原理讲明白的实战笔记。我把整个流程拆成四块来讲先理解I2S在RK3568上是怎么工作的再搞定内核配置和设备树然后过一遍应用层的播放调试方法最后整理几个高频问题。这样一套走下来你不仅能出声还能知道声音是怎么从用户态一步步送到喇叭里的。2. 先把I2S搞明白RK3568到底用哪根线传音频数据2.1 I2S协议五根线每一根都不能少I2SInter-IC Sound是飞利浦在1986年制定的数字音频传输标准专门用于芯片之间的音频数据传输。它在硬件上最典型的形态是五根线但很多板子会把这五根线和I2C的电源线混在一起实际接线时需要格外注意信号名全称方向作用BCLK / SCKBit Clock主机输出每个时钟周期传输一个bit的音频数据LRCLK / WSLeft Right Clock主机输出区分左右声道高电平左声道低电平右声道DACDATA / SDOSerial Data Out主机输出播放时数据从SoC流向CodecADCDATA / SDISerial Data In主机输入录音时数据从Codec流回SoCMCLKMaster Clock主机输出Codec内部时钟基准频率通常是BCLK的整数倍你可以把I2S理解成一条传送带BCLK是传送带的运转节拍每响一下传送一个比特LRCLK是分拣员告诉后续设备这一批货是给左边仓库左声道还是右边仓库右声道DACDATA是传送带上的货物本身MCLK则相当于仓库的总电闸所有内部逻辑都要靠它来驱动。在RK3568上芯片内部集成了多组I2S控制器I2S0、I2S1、I2S2、I2S3部分还支持TDM模式每一组控制器都可以配置为主机或从机模式。绝大多数开发板的设计是RK3568作为I2S主机主动输出BCLK、LRCLK和MCLKCodec作为从机被动接收。2.2 为什么要特别关注MCLK很多第一次调I2S的人会在MCLK上栽跟头。市面上不少Codec芯片尤其是ES8316、WM8960这类内部没有PLL或者PLL的锁定范围很窄必须由主机提供一个频率准确、抖动可控的MCLK才能生成所需的内部时钟。以ES8316为例它的MCLK典型频率是12.288MHz对应48kHz采样率和11.2896MHz对应44.1kHz采样率这两个频率分别等于256倍的48kHz和44.1kHz。如果MCLK频率不对Codec的时钟树就锁定不了表现为播放时完全无声或者声音严重失真。这一条后面在调试部分还会再展开。2.3 I2S标准模式和DSP模式的取舍I2S协议本身有好几种变体常见的有标准I2S飞利浦格式、左对齐Left Justified、右对齐Right Justified以及DSP/PCM格式。它们之间的差别主要在于数据相对于LRCLK的偏移位置。标准I2S格式下数据比LRCLK翻转沿晚一个BCLK周期开始传输。DSP格式则要求数据紧跟着帧同步信号输出延迟可以配置成0到多个BCLK。RK3568的I2S控制器在设备树中用rockchip,format属性来配置可选值有i2s、left_justified、right_justified、dsp_a、dsp_b等。注意Codec芯片手册里写的Audio Data Offset和I2S模式的严格定义必须对齐否则数据时序错位声音会变成持续的滋啦噪音。最稳妥的做法是让SoC和Codec两端都显式配置成标准I2S模式不要依赖默认值。3. 内核配置与ALSA框架让RK3568的I2S控制器先跑起来3.1 内核音频子系统的四位“主角”Linux内核里的音频架构经过多年演进现在已经非常成熟。它在逻辑上分成四个层次用户空间工具层tinyplay、aplay、tinymix等工具直接通过ALSA设备节点与内核交互。ALSA字符设备层提供/dev/snd/pcmC0D0c、/dev/snd/pcmC0D0p、/dev/snd/controlC0等设备节点用户空间的读写最终通过这套节点进入内核。ASoC核心层ASoC即ALSA System on Chip这是嵌入式Linux音频驱动的核心中间层它由三部分组成——Codec驱动描述Codec本身的能力、Platform驱动描述SoC的DMA和DAI控制器、Machine驱动描述Codec和Platform怎么连在一起。硬件层实际的I2S控制器寄存器、DMA引擎、Codec芯片寄存器。这种三段式结构Codec驱动 Platform驱动 Machine驱动是理解整个音频系统的钥匙。你在设备树里做的配置最后都会映射到这三个驱动的交互上。3.2 RK3568相关内核配置项如果内核还没有加入音频相关支持先检查这几项配置。我以Linux 5.10/6.1内核为例路径在Device Drivers → Sound card support下CONFIG_SOUNDy CONFIG_SNDy CONFIG_SND_SOCy CONFIG_SND_SOC_ROCKCHIPy CONFIG_SND_SOC_ROCKCHIP_I2S_TDMy CONFIG_SND_SOC_ROCKCHIP_MACH_DRVy CONFIG_SND_SOC_ES8316y其中CONFIG_SND_SOC_ROCKCHIP_I2S_TDM是RK3568的I2S/TDM控制器驱动CONFIG_SND_SOC_ROCKCHIP_MACH_DRV是通用的Machine驱动CONFIG_SND_SOC_ES8316则需要按你板子上实际用的Codec型号来改。如果用的是WM8960就换成CONFIG_SND_SOC_WM8960y。配置好之后重新编译内核并烧录。这里的坑在于很多人只改了设备树忘了开内核配置或者反过来。两个是配套的少一个都不行。3.3 RK3568设备树里的I2S节点长什么样以RK3568主线内核为例SoC自带的I2S1控制器在arch/arm64/boot/dts/rockchip/rk3568.dtsi中默认定义大致长这样i2s1_8ch: i2sfe410000 { compatible rockchip,rk3568-i2s-tdm; reg 0x0 0xfe410000 0x0 0x1000; interrupts GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH; clocks cru MCLK_I2S1_8CH, cru MCLK_I2S1_8CH_OUT, cru HCLK_I2S1_8CH; clock-names mclk_tx, mclk_rx, hclk; dmas dmac1 0, dmac1 1; dma-names tx, rx; pinctrl-names default; pinctrl-0 i2s1m0_sclk i2s1m0_lrck i2s1m0_sdi0 i2s1m0_sdo0; rockchip,hwirq 0; rockchip,i2s-rx-route 0; rockchip,i2s-tx-route 0; rockchip,const-rate 48000; status disabled; };这些属性里rockchip,hwirq指定控制器使用的是哪个中断处理路径rockchip,i2s-rx-route和rockchip,i2s-tx-route用于选择多路I2S数据线中的哪一路作为录音/播放通道rockchip,const-rate则可以把采样率锁定到固定值常用于蓝牙电话之类的场景。板级设备树文件比如rk3568-evb.dts中会导出一个i2s1节点i2s1_8ch { status okay; };同时还需要定义I2C总线上的Codec节点。以ES8316为例挂在I2C0上地址是0x11i2c0 { status okay; es8316: es831611 { compatible everest,es8316; reg 0x11; clocks cru MCLK_I2S1_8CH_OUT; clock-names mclk; pinctrl-names default; pinctrl-0 i2s1m0_mclk; #sound-dai-cells 0; status okay; }; };这里clocks和clock-names非常关键Codec驱动需要根据这两个属性来请求MCLK并配置自身的时钟树。如果MCLK的父时钟源选错频率就会不对后面调试时会很痛苦。4. 设备树里搭桥Machine驱动如何把I2S和Codec“绑”在一起4.1 为什么还需要一个“声卡”节点有了I2S控制器和Codec各自的节点还不够ALSA系统还需要知道它们两个是怎么连接起来的这就是Machine驱动和sound节点要做的事。你可以把这件事想象成接线I2S控制器是一条已经通到房间门口的水管Codec是房间里的水龙头而sound节点就是焊在墙上的那段接头负责把两头接起来。在RK3568平台上通常使用rockchip,simple-audio-card或者通用的simple-audio-card框架来声明这种连接。以RK3568 EVB板子上的ES8316为例常见写法如下sound { compatible simple-audio-card; simple-audio-card,name RK3568-EVB-AUDIO; simple-audio-card,format i2s; simple-audio-card,mclk-fs 256; simple-audio-card,cpu { sound-dai i2s1_8ch; }; simple-audio-card,codec { sound-dai es8316; }; };simple-audio-card,format i2s指定了两端之间的音频数据格式simple-audio-card,mclk-fs 256则告诉内核CPU要为Codec生成一个频率为采样率256倍的MCLK。44.1kHz的采样率乘以256就是11.2896MHz48kHz乘以256就是12.288MHz刚好对应常见Codec的典型MCLK频率。4.2 为什么建议直接用simple-audio-card早些年的方案是写一个专门的Machine驱动文件比如rk3568_evb.c在驱动里调用snd_soc_register_card()注册声卡再手动设置DAI link。这个办法灵活度高但工作量也大改一个Codec就要改一遍C代码。simple-audio-card的优势在于把大部分逻辑都放到了设备树里内核通过drivers/sound/soc/generic/simple-card.c这个通用驱动来解析节点信息自动完成DAI link的配置。对于绝大多数双声道播放场景它完全够用而且代码量少、不易出错。如果你只需要播放48kHz采样率的音频甚至连额外的Machine驱动都不必写。实测下来主线内核6.1版本对simple-audio-card的支持已经很成熟RK3568平台用它非常顺手。到这里设备树层面的工作基本完成接下来进入编译和调试阶段。5. 从内核启动到出声完整的ALSA调试实战5.1 确认声卡注册成功设备树编译、内核烧录启动后第一件要做的事情是查看声卡节点有没有挂上。进入板子的串口终端执行cat /proc/asound/cards正常情况下会看到类似这样的输出0 [RK3568EVBAUDIO ]: simple-audio_card - RK3568-EVB-AUDIO RK3568-EVB-AUDIO如果这里什么都看不到说明声卡注册失败需要回到设备树检查是否有错误或者用dmesg | grep -i asoc查看内核日志找ASoC: failed to instantiate card之类的关键字。第二步确认PCM设备节点存在ls /dev/snd/预期输出包含controlC0、pcmC0D0c录音和pcmC0D0p播放。pcmC0D0p是ALSA命名规则下的字符设备节点C0代表声卡编号0D0代表设备编号0p是playback播放通道c是capture录音通道。5.2 用tinymix确认Codec工作状态ALSA框架里Codec上几乎所有可配置的模拟/数字控制项都通过tinymix暴露出来。先列出所有控制项tinymix在ES8316上你会看到类似Capture MIC1 boost、DAC volume、ADC PGA gain这样的项。重点检查以下几点DAC是否被静音很多Codec默认上电后DAC是静音状态需要把对应的switch打开。DAC音量是否为零如果音量寄存器默认值是0需要调到一个合理值比如80%。通路选择某些Codec需要在多个输入源之间选择通路播放时选错通路也会导致无声。此时可以直接用命令调节音量tinymix DAC Volume 120 tinymix DAC Switch 1不同Codec的控制项名称差异很大先执行tinymix看清单再逐项确认。5.3 用小工具播放WAV文件验证通路在嵌入式平台上tinyplay是比aplay更常用的播放工具因为它不依赖alsa-lib的复杂配置直接操作/dev/snd节点依赖更少。用法很简单tinyplay /usr/share/sounds/test.wav比如播放一个44.1kHz/16bit/双声道的WAV文件tinyplay会自动解析WAV头然后配置PCM参数开始播放。如果一切正常喇叭就会发出声音。如果想指定参数播放裸数据可以用tinyplay加参数或者用tinyplay /tmp/sine.wav -D 0 -d 0 -p 1024 -n 2这里-D 0指定声卡编号0-d 0指定设备编号0-p 1024指定period size为1024帧-n 2指定使用2个period buffer。这些参数关系到音频播放的延迟和卡顿表现后面会展开讲。5.4 不播放WAV时怎么验证I2S通路是否在工作有时候手头没有现成的WAV文件但你只是想快速确认I2S总线上有没有数据在跑可以用以下两种方式。方法一生成正弦波WAV文件。在PC上用Python生成一个1kHz、持续5秒的WAV拷贝到板子里播放。1kHz音频如果出声能直观判断声道、音质是否正常。import wave import math import struct framerate 44100 duration 5 freq 1000 samples [] for i in range(framerate * duration): val int(32767 * 0.3 * math.sin(2 * math.pi * freq * i / framerate)) samples.append(struct.pack(h, val)) samples.append(struct.pack(h, val)) with wave.open(/tmp/sine_1k.wav, w) as f: f.setnchannels(2) f.setsampwidth(2) f.setframerate(framerate) f.writeframes(b.join(samples))方法二用示波器或逻辑分析仪测量I2S引脚。把探头点在Codec的BCLK引脚上播放时应该能看到频率稳定的方波。比如48kHz采样率、双声道、24bit位宽的情况下BCLK频率大约是48k × 2 × 24 2.304MHz。LRCLK在播放时应该是48kHz的方波。如果LRCLK频率不对或者根本没有波形说明I2S控制器没有正常启动。6. ALSA驱动应用层的四个核心概念PCM设备、Period、Buffer与采样率6.1 ALSA的PCM流模型ALSA把音频播放抽象成一个PCM流模型。应用程序比如tinyplay向PCM设备节点写入PCM数据内核把这些数据拷贝到DMA缓冲区然后I2S控制器通过DMA从缓冲区自动搬运数据发送到Codec。这个模型里有两个关键参数period size一次硬件中断之间传输的帧数。可以把它想象成物流车队的发车节奏——每装满一车一个period就发一趟中断就是通知CPU“车已经开走了可以装下一车”。buffer size总的缓冲区容量由多个period组成。它决定了整个管线能有多长的缓冲时间来吸收CPU调度的抖动。在tinyplay的参数里-p 1024对应period size-n 2表示buffer里有2个period所以总buffer size就是2048帧。6.2 采样率I2S总线上的帧时钟怎么算任何I2S播放最终都要落到“一个字节一个字节从DMA搬到I2S移位寄存器”这个动作上。而搬移的快慢由BCLK决定BCLK 采样率 × 声道数 × 位宽以48kHz采样率、双声道、32bit槽位为例BCLK 48000 × 2 × 32 3072000 Hz 3.072 MHz而MCLK则是采样率乘以mclk-fs配置的倍数。如果设备树里mclk-fs 256那么MCLK就是MCLK 48000 × 256 12288000 Hz 12.288 MHz注意这里有一个很隐蔽的坑I2S控制器硬件并不强制MCLK和BCLK有固定的比值关系但Codec需要靠MCLK来生成内部时钟再反过来同步接收BCLK。如果MCLK频率不是BCLK的合理倍数通常是2、4、8、16、256等Codec的时钟树就锁不住有声但全是噪声或者干脆无声。6.3 为什么同一块板子不同采样率表现天差地别有时候设备树里默认rockchip,const-rate 4800048kHz的音频播放正常但播放44.1kHz音频时要么没声音要么沙沙响。原因就在这里——I2S控制器被锁死在48kHz了44.1kHz的BCLK和LRCLK根本不是它期望的配置。解决这类问题的方法是去掉rockchip,const-rate或者在应用层强制指定播放采样率保证ALSA链路的每一个环节都使用同一个采样率。我一般习惯先在应用层统一等验证通路稳定后再去折腾动态切换采样率的方案。6.4 “播放卡顿”和“播放爆音”各自的根源卡顿CPU来不及填充数据DMA缓冲区空了I2S控制器无数据可发。常见原因是period size太小或者系统负载过高。解决方法是加大period size或者提高进程优先级。爆音数据格式不匹配或时钟不稳定。比如应用层送了24bit数据但ALSA配置成16bit就会错位或者MCLK抖动太大、电源纹波干扰也会表现为周期性爆音。持续的咝咝噪声通常是位宽或声道对齐有问题优先检查format属性比如S16_LE、S24_LE与Codec的slot配置是否一致。7. 实战中避不开的问题RK3568音频调试常见坑与排查手册7.1 I2S引脚被复用导致的无波形RK3568的引脚复用非常灵活同一组引脚可能同时支持UART、I2C、GPIO、I2S等多种功能。设备树里如果I2S1的pinctrl配置与UART2的pinctrl冲突I2S引脚就会被复用掉导致BCLK完全没波形。排查方法是查看实际引脚的复用状态cat /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinmux-pins重点确认GPIO3_B0、GPIO3_B1这类I2S引脚对应的功能是不是i2s1m0相关。如果显示成了gpio或者其他外设功能就要回到设备树调整pinctrl配置。7.2 Codec I2C不通导致声卡注册失败声卡注册失败最常见的原因就是I2C总线探测不到Codec。dmesg里如果看到ES8316: probe failed或者failed to read chip id大概率是I2C地址不对、上拉电阻缺失、或者Codec芯片供电没上电。排查流程确认I2C地址用i2cdetect扫描总线比如ES8316的7bit地址是0x11扫描I2C0就是i2cdetect -y 0如果地址栏里能看到11说明I2C通信没问题。如果扫描不到检查Codec供电和I2C上拉。确认设备树节点里的reg值是否正确。有些Codec的地址引脚可以被配置成多个地址板子实际接法和原理图对不上也会导致探测失败。如果I2C地址对但Codec还是无法注册检查MCLK是否正常。很多Codec的I2C回话功能本身依赖MCLK工作MCLK没接或者没配好I2C也会不正常。7.3 能用aplay出声但tinyplay不出声这两个工具虽然都走ALSA框架但它们的依赖路径不同。aplay会用到alsa-lib的配置文件/usr/share/alsa/alsa.conf如果配置文件里的默认声卡和设备号不正确可能打开的是错误的PCM设备。tinyplay则绕过alsa-lib直接操作设备节点依赖很少在嵌入式平台上更“直给”。遇到这种情况优先用tinyplay来确定硬件通路是否OK。如果tinyplay能出声说明硬件链路没问题只需要修正alsa配置文件即可把defaults.pcm.card 0和defaults.pcm.device 0改成正确的值。7.4 播放过程中收到“Resource busy”错误这个错误说明PCM设备被其他进程占用了。RK3568的I2S控制器在指定时刻通常只允许一个播放流和一个录音流存在。如果之前有进程异常退出但没释放设备节点就需要杀掉残留进程ps aux | grep -E tinyplay|aplay killall tinyplay更彻底的办法是直接恢复ALSA设备状态echo 1 /sys/class/sound/card0/device/remove echo 1 /sys/class/sound/card0/device/rescan7.5 有用到HDMI或DP音频时声卡编号会变RK3568同时支持HDMI/DP音频输出这些音频接口在ALSA里会注册成额外的声卡。声卡0可能是HDMI声卡1才是你的I2S Codec声卡如果应用层默认写死hw:0,0就会打开错误的设备。解决方法是优先使用plughw或者通过/proc/asound/cards查看实际编号再在应用层用声卡名比如hw:RK3568EVBAUDIO,0代替数字编号。8. 一些经验心得先把通路跑通再谈音质调音频驱动最忌讳一开始就想同时搞定所有环节。我的个人习惯是分四步走第一步确认I2C能探测到Codec这是所有工作的前提。就算其他都不正常只要I2C通你还能通过寄存器读写来排查I2C不通就只能盲猜。第二步确认I2S引脚有波形直接看BCLK和LRCLK。不播放音频时这两根线应该是低电平或高阻态一旦开始播放就必须有稳定的时钟信号。第三步用tinymix恢复Codec默认音量设置打开所有可能影响通路的switch把数字和模拟增益调到中间值确保没有静音。第四步播放1kHz正弦波测试音这是最快定位问题的信号。听到的是纯音说明通路基本OK听到的是爆裂声或者噪声优先怀疑时钟配置或数据格式错误。最后再分享一个小技巧在调试Codec时把CONFIG_DEBUG_FSy打开然后挂载debugfs。在/sys/kernel/debug/asoc/目录下能看到完整的ASoC组件拓扑树包含每个DAI link的连接关系调试阶段没事翻一翻能少走很多弯路。音频驱动的整个链路从物理引脚到应用层工具环环相扣耐心顺着链路一层层排查最终一定能找到问题所在。