1. 项目缘起与整体设计思路1.1 为什么要在RK3506上折腾DSM音频RK3506这颗芯片在工业控制和音频处理场景里出现得越来越多三核Cortex-A7加一颗Cortex-M0的异构架构功耗低、接口全价格也压得住。但真正拿到开发板上跑DSMDigital Signal Processing Module数字信号处理模块音频链路的时候你会发现官方文档给的信息远远不够用。尤其是SAI3这个接口它不像SAI1/SAI2那样在参考设计里被反复验证过很多细节需要自己踩出来。我这次接到的需求是在RK3506开发板上实现一路DSM音频采集与回放采样率48kHz、16bit、双声道通过SAI3接口对接外部Codec。听起来不复杂但实际做下来从硬件改接到内核配置再到用户态验证前后花了将近一周时间。中间遇到的坑包括引脚复用冲突、时钟树配置错误、DMA缓冲区对齐问题、设备树节点顺序导致的probe失败等等。这些问题的共同特点是报错信息不直观官方文档没覆盖社区里搜到的答案大多针对RK3568或RV1106直接套用会翻车。所以我把整个流程整理出来一方面是给自己留个记录另一方面也是让后面做类似项目的兄弟少走弯路。这篇文章会从硬件改接开始一步步讲到内核配置、设备树编写、驱动调试和用户态验证每个环节都会说明为什么这么做以及不做会出什么问题。1.2 整体方案选型与架构说明在动手之前先明确整个音频链路的架构。RK3506的SAI3接口支持I2S、PCM、TDM等模式我们用的是标准I2S模式主模式Master由RK3506提供BCLK和LRCK外部Codec作为从设备。数据流方向是双向的播放时数据从内存经SAI3 TX到Codec录音时数据从Codec经SAI3 RX到内存。为什么选SAI3而不是SAI1或SAI2因为开发板上SAI1和SAI2已经被其他功能占用了SAI3是唯一可用的音频接口。这也是很多实际项目中的常见情况——不是你选接口而是接口选你。SAI3的引脚在RK3506上默认功能不是I2S需要先做引脚复用配置pinctrl这是第一个容易出问题的地方。软件层面内核版本用的是RK官方提供的5.10内核ALSA SoC框架。DSM模块本身是运行在用户态的算法库通过ALSA的PCM接口读写音频数据。所以整条链路是外部Codec - SAI3 - ALSA DAI - ALSA PCM - 用户态DSM算法。每一层都有各自的配置要点后面会逐一展开。注意RK3506的SAI3在部分开发板原理图上标注为“SAI3_MCLK”“SAI3_SCLK”“SAI3_LRCK”“SAI3_SDI”“SAI3_SDO”但实际引脚编号和复用寄存器可能和RK3568不同不能直接照搬RK3568的设备树。2. 硬件改接与引脚复用配置2.1 开发板硬件排查与改接要点拿到开发板第一件事不是写代码而是对着原理图确认SAI3的引脚到底引到了哪里。我手上这块板子的SAI3信号通过排针引出但默认没有焊接上拉电阻和耦合电容需要自己补。具体来说SAI3_MCLK、SAI3_SCLK、SAI3_LRCK、SAI3_SDI、SAI3_SDO这五根信号线在排针上都有但Codec那边的MCLK输入需要主时钟而开发板默认没有把SAI3_MCLK接到排针上只引出了SCLK和LRCK。这就意味着如果你直接用SCLK当MCLK给CodecCodec可能无法正常工作因为很多Codec要求MCLK是采样率的256倍或512倍而SCLK是采样率的64倍I2S标准。我一开始就是吃了这个亏Codec一直不出声示波器量SCLK和LRCK都正常但Codec的MCLK引脚没有信号。后来查原理图才发现SAI3_MCLK根本没引出来只能从芯片旁边的测试点飞线。改接方案如下从RK3506芯片旁边的MCLK测试点飞一根线到Codec的MCLK输入同时确保SCLK、LRCK、SDI、SDO四根线连接正确。另外Codec的电源和地要单独处理模拟地和数字地通过磁珠隔离否则底噪会很大。这些是硬件层面的基本功但往往被忽略。实操心得飞线的时候尽量短最好不超过5厘米否则MCLK信号质量会下降导致Codec锁相环失锁。我试过用10厘米的杜邦线结果Codec时好时坏换成5厘米的漆包线后稳定了。2.2 引脚复用寄存器配置与验证RK3506的引脚复用通过GRFGeneral Register File寄存器控制每个引脚有对应的复用选择位。SAI3的引脚默认可能是GPIO或其他功能需要配置为SAI3功能。具体寄存器地址和位定义在RK3506的TRM技术参考手册里有但手册写得很分散需要自己拼。以SAI3_SCLK为例假设它对应GPIO3_A1那么需要找到GPIO3A_IOMUX_SEL_L寄存器具体地址查手册把对应的4位设置为SAI3_SCLK的功能编号。这个功能编号每个引脚不同不能想当然。我建议的做法是先在U-Boot里用md命令读取寄存器默认值然后修改再读回来确认。这样比直接在内核里改设备树更直观因为U-Boot阶段就能验证引脚复用是否生效。验证方法用示波器或逻辑分析仪量引脚如果配置成功播放音频时应该能看到SCLK和LRCK波形。如果没有波形要么是复用没配好要么是SAI3控制器没使能。这一步一定要在硬件层面确认不要等到内核启动后再排查否则问题会混在一起。# 在U-Boot中读取GPIO3A_IOMUX_SEL_L寄存器地址仅为示例 md 0xFF3B0000 1 # 修改为SAI3功能 mw 0xFF3B0000 0x00010000 # 读回确认 md 0xFF3B0000 12.3 硬件改接后的信号完整性检查硬件改接完成后不要急着上电跑系统先用万用表检查一遍电源对地是否短路、信号线是否虚焊、MCLK飞线是否牢固。然后上电用示波器看MCLK、SCLK、LRCK的波形。正常情况下MCLK应该是SCLK的4倍或8倍取决于Codec配置LRCK频率等于采样率。如果波形异常比如MCLK幅度不够、SCLK占空比不对先检查RK3506的SAI3时钟配置。RK3506的SAI3时钟源来自CPLL或GPLL分频系数在CRUClock Reset Unit里设置。如果分频不对SCLK频率就会错Codec无法同步。我遇到过SCLK频率是预期的一半原因是分频系数算错了后面在时钟配置章节会详细说。3. 内核配置与设备树编写3.1 内核选项裁剪与SAI3驱动使能RK3506的官方内核默认可能没有使能SAI3驱动需要自己配置。进入内核源码目录执行make menuconfig找到以下选项Device Drivers - Sound card support - Advanced Linux Sound Architecture - ALSA for SoC audio support - Rockchip SAI support确保Rockchip SAI3被选中同时使能Rockchip I2S/TDM support因为SAI3驱动依赖它另外如果要用DSM算法用户态需要ALSA的PCM接口所以Device Drivers - Sound card support - Advanced Linux Sound Architecture - PCM也要使能。这些选项在默认配置里可能是模块M建议编译进内核Y避免启动时模块加载顺序问题。配置完成后编译内核和设备树烧录到开发板。启动后检查/proc/asound/cards如果看到SAI3对应的声卡说明驱动加载成功。如果没有检查内核日志dmesg | grep sai看是否有probe失败的信息。注意RK3506的内核配置和RK3568有差异不能直接复制RK3568的defconfig。我试过用RK3568的配置结果SAI3驱动编译报错因为寄存器定义不同。3.2 设备树节点编写与关键属性解析设备树是RK3506音频配置的核心写错了驱动就probe不了。以下是一个可用的SAI3设备树节点示例基于我实际调试通过的版本sai3 { status okay; #sound-dai-cells 0; compatible rockchip,rk3506-sai, rockchip,rk3568-sai; reg 0x0 0xff3b0000 0x0 0x1000; interrupts GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH; clocks cru MCLK_SAI3, cru HCLK_SAI3; clock-names mclk, hclk; dmas dmac1 4, dmac1 5; dma-names tx, rx; pinctrl-names default; pinctrl-0 sai3m0_pins; rockchip,playback-channels 2; rockchip,capture-channels 2; rockchip,grf grf; rockchip,bclk-fs 64; rockchip,mclk-fs 256; status okay; };关键属性说明compatibleRK3506的SAI3兼容RK3568的驱动但最好加上RK3506自己的兼容字符串方便后续区分。clocks和clock-namesMCLK和HCLK必须正确否则时钟使能失败。dmas和dma-namesTX和RX的DMA通道要对应RK3506的DMA控制器和RK3568不同通道号要查手册。pinctrl-0引用引脚复用节点这个节点要在pinctrl子系统里定义。rockchip,bclk-fs和rockchip,mclk-fs分别设置BCLK和MCLK与采样率的倍数关系I2S标准是BCLK64fsMCLK256fs。pinctrl节点示例pinctrl { sai3 { sai3m0_pins: sai3m0-pins { rockchip,pins 3 RK_PA0 4 pcfg_pull_none, /* SCLK */ 3 RK_PA1 4 pcfg_pull_none, /* LRCK */ 3 RK_PA2 4 pcfg_pull_none, /* SDI */ 3 RK_PA3 4 pcfg_pull_none, /* SDO */ 3 RK_PA4 4 pcfg_pull_none; /* MCLK */ }; }; };这里的3是GPIO bankRK_PA0是引脚号4是复用功能编号。这个编号一定要查RK3506的datasheet不能照搬RK3568。3.3 时钟树配置与分频系数计算RK3506的SAI3时钟源可以选择CPLL、GPLL或USB480M等。假设我们选CPLL频率是1188MHz要得到MCLK12.288MHz48kHz * 256分频系数是1188/12.28896.67不是整数。所以需要先调整CPLL频率或者选其他时钟源。实际做法在设备树里设置assigned-clocks和assigned-clock-rates让内核自动计算分频。例如sai3 { assigned-clocks cru MCLK_SAI3; assigned-clock-rates 12288000; };这样内核会从父时钟里选一个能分出12.288MHz的源并自动设置分频系数。如果父时钟都不合适就需要在CRU驱动里改CPLL频率。我遇到过CPLL默认频率分不出12.288MHz的情况最后是把CPLL调到1179.648MHz12.288 * 96这样分频系数是整数96MCLK正好12.288MHz。提示MCLK频率必须是采样率的整数倍且最好是256或512倍。如果MCLK有偏差Codec的PLL可能锁不住表现为播放速度不对或录音有杂音。4. 驱动调试与用户态验证4.1 驱动probe失败常见原因与排查驱动probe失败是调试阶段最常见的问题。dmesg里通常会打印错误码比如-EPROBE_DEFER、-EINVAL、-ENODEV。根据我的经验原因主要有以下几类错误码可能原因排查方法-EPROBE_DEFER依赖的时钟或pinctrl未就绪检查clocks和pinctrl节点是否被其他驱动占用-EINVAL设备树属性值非法检查bclk-fs、mclk-fs是否合理-ENODEV寄存器地址或中断号错误对照TRM确认reg和interrupts-EBUSYDMA通道被占用检查dmas属性是否与其他外设冲突我遇到过一次-EPROBE_DEFER原因是pinctrl节点定义在sai3节点之后内核解析设备树时pinctrl还没注册。解决办法是把pinctrl节点移到sai3节点之前或者用pinctrl-0引用时确保phandle有效。另一个坑是DMA通道号。RK3506的DMA控制器有多个每个控制器的通道数不同。如果dmas属性里写的通道号超出了控制器的范围probe会失败。我建议先在设备树里只使能TX确认TX正常后再加RX这样容易定位问题。4.2 ALSA工具验证与DSM音频链路测试驱动probe成功后用aplay -l和arecord -l查看声卡设备。正常情况下应该看到类似card 0: RKSAI3 [rockchip-sai3], device 0: ff3b0000.sai3-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0然后可以用aplay播放一个WAV文件测试aplay -D hw:0,0 test.wav如果听不到声音先检查Codec的配置比如寄存器初始化再检查SAI3的格式是否匹配I2S、16bit、48kHz。可以用speaker-test生成测试音speaker-test -D hw:0,0 -c 2 -r 48000 -t sine -f 1000录音测试用arecordarecord -D hw:0,0 -f S16_LE -r 48000 -c 2 -d 5 test_record.wav录完后用aplay回放确认录音链路正常。如果录音有杂音检查MCLK是否稳定、模拟地是否干净。DSM算法本身是用户态程序通过ALSA的PCM接口读写数据。我写了一个简单的测试程序打开PCM设备配置参数然后循环读写。关键点是PCM缓冲区大小和周期大小的设置如果设置不当会出现XRUN缓冲区欠载或溢出。建议周期大小设为1024帧缓冲区设为4096帧这样延迟和稳定性比较平衡。4.3 常见问题速查表与避坑技巧以下是我在实际调试中遇到的问题和解决方法整理成速查表现象可能原因解决方法播放无声Codec未初始化检查Codec驱动和寄存器配置录音全是噪声MCLK频率不对用示波器量MCLK调整分频播放速度不对LRCK频率错误检查bclk-fs和mclk-fsXRUN频繁缓冲区太小增大period和buffer sizeprobe失败设备树属性错误对照TRM逐项检查只有单声道通道配置错误检查playback-channels和capture-channels独家避坑技巧RK3506的SAI3在同时使用TX和RX时DMA通道要分开不能共用。我一开始把TX和RX配到同一个DMA通道结果播放正常但录音没数据。后来改成两个独立通道就好了。另外如果Codec需要MCLK一定要确保MCLK在SAI3使能之前就稳定输出否则Codec可能初始化失败。可以在设备树里设置assigned-clock-rates让MCLK先于SAI3使能。5. 性能优化与稳定性调优5.1 音频延迟与缓冲区调优DSM音频链路对延迟敏感如果缓冲区设得太大算法处理会有明显延迟设得太小又容易XRUN。我的经验是先确定DSM算法的处理周期比如每10ms处理一帧那么ALSA的period size就设为480帧48kHz * 10msbuffer size设为4倍period即1920帧。这样既能保证算法有足够时间处理又不会引入太大延迟。调整方法在用户态程序里用snd_pcm_hw_params_set_period_size_near和snd_pcm_hw_params_set_buffer_size_near设置。如果XRUN仍然频繁可以适当增大buffer size但不要超过8倍period否则延迟会超过20ms对于实时音频处理来说太大了。实操心得我试过period size256帧buffer size1024帧结果XRUN频繁因为DSM算法处理一帧需要的时间超过了5.3ms。后来改成period size512帧buffer size2048帧就稳定了。所以period size要根据算法处理时间来定不能拍脑袋。5.2 长时间运行稳定性测试音频链路跑短时间没问题不代表长时间稳定。我做过72小时连续播放和录音测试中间遇到过DMA溢出、内存泄漏、时钟漂移等问题。DMA溢出通常是因为缓冲区管理不当比如用户态程序读数据太慢导致DMA写满后覆盖。解决办法是增加一个环形缓冲区用户态程序从环形缓冲区读数据而不是直接从ALSA读。内存泄漏方面ALSA的PCM接口在打开和关闭时要注意释放资源。我写了一个测试程序每10分钟重新打开一次PCM设备跑24小时后发现内存增长了几十MB后来发现是snd_pcm_close没有调用。加上之后内存就稳定了。时钟漂移表现为长时间播放后音视频不同步如果有视频的话或者录音和播放的采样率有微小偏差。RK3506的CPLL精度足够一般不会漂移但如果Codec的PLL精度不够可能会有累积误差。解决办法是定期用MCLK同步或者选用高精度晶振的Codec。5.3 与其他外设的协同工作RK3506上SAI3可能和其他外设共享时钟或DMA资源。比如如果同时使用SPI和SAI3DMA通道可能会冲突。我遇到过SPI传输时音频出现咔嗒声原因是SPI的DMA优先级比SAI3高抢占了总线。解决办法是在DMA控制器里调整优先级或者把SPI的DMA通道换到另一个控制器。另外如果系统里有多个音频接口比如HDMI音频和SAI3ALSA的默认声卡可能会变。可以在/etc/asound.conf里指定默认声卡pcm.!default { type hw card 0 } ctl.!default { type hw card 0 }这样用户态程序不用每次指定-D hw:0,0直接用默认设备就行。6. 个人经验总结与后续扩展整个项目做下来最大的体会是RK3506的SAI3音频开发硬件改接和时钟配置占了70%的工作量内核和设备树只占30%。很多问题不是软件能解决的必须从硬件层面排查。比如MCLK飞线、电源滤波、地平面处理这些基本功做不好后面软件调死也出不来好声音。另外官方文档和社区资料对RK3506的支持还不够完善很多地方需要自己查TRM和实测。我建议做类似项目的兄弟先花时间把TRM里SAI3和CRU的章节读透然后用U-Boot和示波器验证硬件最后再写内核和设备树。这样排查问题的路径最短效率最高。后续如果要做多路SAI或者TDM模式还需要研究RK3506的SAI3是否支持多通道复用以及DMA的带宽是否够用。我目前只做了双声道I2STDM模式还没试过等后面有需求再折腾。如果你也在做RK3506音频开发欢迎交流踩坑经验。
RK3506 SAI3 DSM音频链路开发实战：硬件改接到驱动调试
1. 项目缘起与整体设计思路1.1 为什么要在RK3506上折腾DSM音频RK3506这颗芯片在工业控制和音频处理场景里出现得越来越多三核Cortex-A7加一颗Cortex-M0的异构架构功耗低、接口全价格也压得住。但真正拿到开发板上跑DSMDigital Signal Processing Module数字信号处理模块音频链路的时候你会发现官方文档给的信息远远不够用。尤其是SAI3这个接口它不像SAI1/SAI2那样在参考设计里被反复验证过很多细节需要自己踩出来。我这次接到的需求是在RK3506开发板上实现一路DSM音频采集与回放采样率48kHz、16bit、双声道通过SAI3接口对接外部Codec。听起来不复杂但实际做下来从硬件改接到内核配置再到用户态验证前后花了将近一周时间。中间遇到的坑包括引脚复用冲突、时钟树配置错误、DMA缓冲区对齐问题、设备树节点顺序导致的probe失败等等。这些问题的共同特点是报错信息不直观官方文档没覆盖社区里搜到的答案大多针对RK3568或RV1106直接套用会翻车。所以我把整个流程整理出来一方面是给自己留个记录另一方面也是让后面做类似项目的兄弟少走弯路。这篇文章会从硬件改接开始一步步讲到内核配置、设备树编写、驱动调试和用户态验证每个环节都会说明为什么这么做以及不做会出什么问题。1.2 整体方案选型与架构说明在动手之前先明确整个音频链路的架构。RK3506的SAI3接口支持I2S、PCM、TDM等模式我们用的是标准I2S模式主模式Master由RK3506提供BCLK和LRCK外部Codec作为从设备。数据流方向是双向的播放时数据从内存经SAI3 TX到Codec录音时数据从Codec经SAI3 RX到内存。为什么选SAI3而不是SAI1或SAI2因为开发板上SAI1和SAI2已经被其他功能占用了SAI3是唯一可用的音频接口。这也是很多实际项目中的常见情况——不是你选接口而是接口选你。SAI3的引脚在RK3506上默认功能不是I2S需要先做引脚复用配置pinctrl这是第一个容易出问题的地方。软件层面内核版本用的是RK官方提供的5.10内核ALSA SoC框架。DSM模块本身是运行在用户态的算法库通过ALSA的PCM接口读写音频数据。所以整条链路是外部Codec - SAI3 - ALSA DAI - ALSA PCM - 用户态DSM算法。每一层都有各自的配置要点后面会逐一展开。注意RK3506的SAI3在部分开发板原理图上标注为“SAI3_MCLK”“SAI3_SCLK”“SAI3_LRCK”“SAI3_SDI”“SAI3_SDO”但实际引脚编号和复用寄存器可能和RK3568不同不能直接照搬RK3568的设备树。2. 硬件改接与引脚复用配置2.1 开发板硬件排查与改接要点拿到开发板第一件事不是写代码而是对着原理图确认SAI3的引脚到底引到了哪里。我手上这块板子的SAI3信号通过排针引出但默认没有焊接上拉电阻和耦合电容需要自己补。具体来说SAI3_MCLK、SAI3_SCLK、SAI3_LRCK、SAI3_SDI、SAI3_SDO这五根信号线在排针上都有但Codec那边的MCLK输入需要主时钟而开发板默认没有把SAI3_MCLK接到排针上只引出了SCLK和LRCK。这就意味着如果你直接用SCLK当MCLK给CodecCodec可能无法正常工作因为很多Codec要求MCLK是采样率的256倍或512倍而SCLK是采样率的64倍I2S标准。我一开始就是吃了这个亏Codec一直不出声示波器量SCLK和LRCK都正常但Codec的MCLK引脚没有信号。后来查原理图才发现SAI3_MCLK根本没引出来只能从芯片旁边的测试点飞线。改接方案如下从RK3506芯片旁边的MCLK测试点飞一根线到Codec的MCLK输入同时确保SCLK、LRCK、SDI、SDO四根线连接正确。另外Codec的电源和地要单独处理模拟地和数字地通过磁珠隔离否则底噪会很大。这些是硬件层面的基本功但往往被忽略。实操心得飞线的时候尽量短最好不超过5厘米否则MCLK信号质量会下降导致Codec锁相环失锁。我试过用10厘米的杜邦线结果Codec时好时坏换成5厘米的漆包线后稳定了。2.2 引脚复用寄存器配置与验证RK3506的引脚复用通过GRFGeneral Register File寄存器控制每个引脚有对应的复用选择位。SAI3的引脚默认可能是GPIO或其他功能需要配置为SAI3功能。具体寄存器地址和位定义在RK3506的TRM技术参考手册里有但手册写得很分散需要自己拼。以SAI3_SCLK为例假设它对应GPIO3_A1那么需要找到GPIO3A_IOMUX_SEL_L寄存器具体地址查手册把对应的4位设置为SAI3_SCLK的功能编号。这个功能编号每个引脚不同不能想当然。我建议的做法是先在U-Boot里用md命令读取寄存器默认值然后修改再读回来确认。这样比直接在内核里改设备树更直观因为U-Boot阶段就能验证引脚复用是否生效。验证方法用示波器或逻辑分析仪量引脚如果配置成功播放音频时应该能看到SCLK和LRCK波形。如果没有波形要么是复用没配好要么是SAI3控制器没使能。这一步一定要在硬件层面确认不要等到内核启动后再排查否则问题会混在一起。# 在U-Boot中读取GPIO3A_IOMUX_SEL_L寄存器地址仅为示例 md 0xFF3B0000 1 # 修改为SAI3功能 mw 0xFF3B0000 0x00010000 # 读回确认 md 0xFF3B0000 12.3 硬件改接后的信号完整性检查硬件改接完成后不要急着上电跑系统先用万用表检查一遍电源对地是否短路、信号线是否虚焊、MCLK飞线是否牢固。然后上电用示波器看MCLK、SCLK、LRCK的波形。正常情况下MCLK应该是SCLK的4倍或8倍取决于Codec配置LRCK频率等于采样率。如果波形异常比如MCLK幅度不够、SCLK占空比不对先检查RK3506的SAI3时钟配置。RK3506的SAI3时钟源来自CPLL或GPLL分频系数在CRUClock Reset Unit里设置。如果分频不对SCLK频率就会错Codec无法同步。我遇到过SCLK频率是预期的一半原因是分频系数算错了后面在时钟配置章节会详细说。3. 内核配置与设备树编写3.1 内核选项裁剪与SAI3驱动使能RK3506的官方内核默认可能没有使能SAI3驱动需要自己配置。进入内核源码目录执行make menuconfig找到以下选项Device Drivers - Sound card support - Advanced Linux Sound Architecture - ALSA for SoC audio support - Rockchip SAI support确保Rockchip SAI3被选中同时使能Rockchip I2S/TDM support因为SAI3驱动依赖它另外如果要用DSM算法用户态需要ALSA的PCM接口所以Device Drivers - Sound card support - Advanced Linux Sound Architecture - PCM也要使能。这些选项在默认配置里可能是模块M建议编译进内核Y避免启动时模块加载顺序问题。配置完成后编译内核和设备树烧录到开发板。启动后检查/proc/asound/cards如果看到SAI3对应的声卡说明驱动加载成功。如果没有检查内核日志dmesg | grep sai看是否有probe失败的信息。注意RK3506的内核配置和RK3568有差异不能直接复制RK3568的defconfig。我试过用RK3568的配置结果SAI3驱动编译报错因为寄存器定义不同。3.2 设备树节点编写与关键属性解析设备树是RK3506音频配置的核心写错了驱动就probe不了。以下是一个可用的SAI3设备树节点示例基于我实际调试通过的版本sai3 { status okay; #sound-dai-cells 0; compatible rockchip,rk3506-sai, rockchip,rk3568-sai; reg 0x0 0xff3b0000 0x0 0x1000; interrupts GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH; clocks cru MCLK_SAI3, cru HCLK_SAI3; clock-names mclk, hclk; dmas dmac1 4, dmac1 5; dma-names tx, rx; pinctrl-names default; pinctrl-0 sai3m0_pins; rockchip,playback-channels 2; rockchip,capture-channels 2; rockchip,grf grf; rockchip,bclk-fs 64; rockchip,mclk-fs 256; status okay; };关键属性说明compatibleRK3506的SAI3兼容RK3568的驱动但最好加上RK3506自己的兼容字符串方便后续区分。clocks和clock-namesMCLK和HCLK必须正确否则时钟使能失败。dmas和dma-namesTX和RX的DMA通道要对应RK3506的DMA控制器和RK3568不同通道号要查手册。pinctrl-0引用引脚复用节点这个节点要在pinctrl子系统里定义。rockchip,bclk-fs和rockchip,mclk-fs分别设置BCLK和MCLK与采样率的倍数关系I2S标准是BCLK64fsMCLK256fs。pinctrl节点示例pinctrl { sai3 { sai3m0_pins: sai3m0-pins { rockchip,pins 3 RK_PA0 4 pcfg_pull_none, /* SCLK */ 3 RK_PA1 4 pcfg_pull_none, /* LRCK */ 3 RK_PA2 4 pcfg_pull_none, /* SDI */ 3 RK_PA3 4 pcfg_pull_none, /* SDO */ 3 RK_PA4 4 pcfg_pull_none; /* MCLK */ }; }; };这里的3是GPIO bankRK_PA0是引脚号4是复用功能编号。这个编号一定要查RK3506的datasheet不能照搬RK3568。3.3 时钟树配置与分频系数计算RK3506的SAI3时钟源可以选择CPLL、GPLL或USB480M等。假设我们选CPLL频率是1188MHz要得到MCLK12.288MHz48kHz * 256分频系数是1188/12.28896.67不是整数。所以需要先调整CPLL频率或者选其他时钟源。实际做法在设备树里设置assigned-clocks和assigned-clock-rates让内核自动计算分频。例如sai3 { assigned-clocks cru MCLK_SAI3; assigned-clock-rates 12288000; };这样内核会从父时钟里选一个能分出12.288MHz的源并自动设置分频系数。如果父时钟都不合适就需要在CRU驱动里改CPLL频率。我遇到过CPLL默认频率分不出12.288MHz的情况最后是把CPLL调到1179.648MHz12.288 * 96这样分频系数是整数96MCLK正好12.288MHz。提示MCLK频率必须是采样率的整数倍且最好是256或512倍。如果MCLK有偏差Codec的PLL可能锁不住表现为播放速度不对或录音有杂音。4. 驱动调试与用户态验证4.1 驱动probe失败常见原因与排查驱动probe失败是调试阶段最常见的问题。dmesg里通常会打印错误码比如-EPROBE_DEFER、-EINVAL、-ENODEV。根据我的经验原因主要有以下几类错误码可能原因排查方法-EPROBE_DEFER依赖的时钟或pinctrl未就绪检查clocks和pinctrl节点是否被其他驱动占用-EINVAL设备树属性值非法检查bclk-fs、mclk-fs是否合理-ENODEV寄存器地址或中断号错误对照TRM确认reg和interrupts-EBUSYDMA通道被占用检查dmas属性是否与其他外设冲突我遇到过一次-EPROBE_DEFER原因是pinctrl节点定义在sai3节点之后内核解析设备树时pinctrl还没注册。解决办法是把pinctrl节点移到sai3节点之前或者用pinctrl-0引用时确保phandle有效。另一个坑是DMA通道号。RK3506的DMA控制器有多个每个控制器的通道数不同。如果dmas属性里写的通道号超出了控制器的范围probe会失败。我建议先在设备树里只使能TX确认TX正常后再加RX这样容易定位问题。4.2 ALSA工具验证与DSM音频链路测试驱动probe成功后用aplay -l和arecord -l查看声卡设备。正常情况下应该看到类似card 0: RKSAI3 [rockchip-sai3], device 0: ff3b0000.sai3-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0然后可以用aplay播放一个WAV文件测试aplay -D hw:0,0 test.wav如果听不到声音先检查Codec的配置比如寄存器初始化再检查SAI3的格式是否匹配I2S、16bit、48kHz。可以用speaker-test生成测试音speaker-test -D hw:0,0 -c 2 -r 48000 -t sine -f 1000录音测试用arecordarecord -D hw:0,0 -f S16_LE -r 48000 -c 2 -d 5 test_record.wav录完后用aplay回放确认录音链路正常。如果录音有杂音检查MCLK是否稳定、模拟地是否干净。DSM算法本身是用户态程序通过ALSA的PCM接口读写数据。我写了一个简单的测试程序打开PCM设备配置参数然后循环读写。关键点是PCM缓冲区大小和周期大小的设置如果设置不当会出现XRUN缓冲区欠载或溢出。建议周期大小设为1024帧缓冲区设为4096帧这样延迟和稳定性比较平衡。4.3 常见问题速查表与避坑技巧以下是我在实际调试中遇到的问题和解决方法整理成速查表现象可能原因解决方法播放无声Codec未初始化检查Codec驱动和寄存器配置录音全是噪声MCLK频率不对用示波器量MCLK调整分频播放速度不对LRCK频率错误检查bclk-fs和mclk-fsXRUN频繁缓冲区太小增大period和buffer sizeprobe失败设备树属性错误对照TRM逐项检查只有单声道通道配置错误检查playback-channels和capture-channels独家避坑技巧RK3506的SAI3在同时使用TX和RX时DMA通道要分开不能共用。我一开始把TX和RX配到同一个DMA通道结果播放正常但录音没数据。后来改成两个独立通道就好了。另外如果Codec需要MCLK一定要确保MCLK在SAI3使能之前就稳定输出否则Codec可能初始化失败。可以在设备树里设置assigned-clock-rates让MCLK先于SAI3使能。5. 性能优化与稳定性调优5.1 音频延迟与缓冲区调优DSM音频链路对延迟敏感如果缓冲区设得太大算法处理会有明显延迟设得太小又容易XRUN。我的经验是先确定DSM算法的处理周期比如每10ms处理一帧那么ALSA的period size就设为480帧48kHz * 10msbuffer size设为4倍period即1920帧。这样既能保证算法有足够时间处理又不会引入太大延迟。调整方法在用户态程序里用snd_pcm_hw_params_set_period_size_near和snd_pcm_hw_params_set_buffer_size_near设置。如果XRUN仍然频繁可以适当增大buffer size但不要超过8倍period否则延迟会超过20ms对于实时音频处理来说太大了。实操心得我试过period size256帧buffer size1024帧结果XRUN频繁因为DSM算法处理一帧需要的时间超过了5.3ms。后来改成period size512帧buffer size2048帧就稳定了。所以period size要根据算法处理时间来定不能拍脑袋。5.2 长时间运行稳定性测试音频链路跑短时间没问题不代表长时间稳定。我做过72小时连续播放和录音测试中间遇到过DMA溢出、内存泄漏、时钟漂移等问题。DMA溢出通常是因为缓冲区管理不当比如用户态程序读数据太慢导致DMA写满后覆盖。解决办法是增加一个环形缓冲区用户态程序从环形缓冲区读数据而不是直接从ALSA读。内存泄漏方面ALSA的PCM接口在打开和关闭时要注意释放资源。我写了一个测试程序每10分钟重新打开一次PCM设备跑24小时后发现内存增长了几十MB后来发现是snd_pcm_close没有调用。加上之后内存就稳定了。时钟漂移表现为长时间播放后音视频不同步如果有视频的话或者录音和播放的采样率有微小偏差。RK3506的CPLL精度足够一般不会漂移但如果Codec的PLL精度不够可能会有累积误差。解决办法是定期用MCLK同步或者选用高精度晶振的Codec。5.3 与其他外设的协同工作RK3506上SAI3可能和其他外设共享时钟或DMA资源。比如如果同时使用SPI和SAI3DMA通道可能会冲突。我遇到过SPI传输时音频出现咔嗒声原因是SPI的DMA优先级比SAI3高抢占了总线。解决办法是在DMA控制器里调整优先级或者把SPI的DMA通道换到另一个控制器。另外如果系统里有多个音频接口比如HDMI音频和SAI3ALSA的默认声卡可能会变。可以在/etc/asound.conf里指定默认声卡pcm.!default { type hw card 0 } ctl.!default { type hw card 0 }这样用户态程序不用每次指定-D hw:0,0直接用默认设备就行。6. 个人经验总结与后续扩展整个项目做下来最大的体会是RK3506的SAI3音频开发硬件改接和时钟配置占了70%的工作量内核和设备树只占30%。很多问题不是软件能解决的必须从硬件层面排查。比如MCLK飞线、电源滤波、地平面处理这些基本功做不好后面软件调死也出不来好声音。另外官方文档和社区资料对RK3506的支持还不够完善很多地方需要自己查TRM和实测。我建议做类似项目的兄弟先花时间把TRM里SAI3和CRU的章节读透然后用U-Boot和示波器验证硬件最后再写内核和设备树。这样排查问题的路径最短效率最高。后续如果要做多路SAI或者TDM模式还需要研究RK3506的SAI3是否支持多通道复用以及DMA的带宽是否够用。我目前只做了双声道I2STDM模式还没试过等后面有需求再折腾。如果你也在做RK3506音频开发欢迎交流踩坑经验。
