瑞芯微RV1106开发板录音失败手把手教你排查rkipc进程占用音频设备问题做RV1106开发板项目的时候遇到一个特别典型的场景板子跑起来了系统也起来了程序编译下载都没问题唯独调用录音接口的时候要么返回设备忙要么直接没数据。查了一圈发现是自带的rkipc这个媒体服务进程把音频设备给占了。这个坑其实非常普遍尤其是刚接触RV1106、RV1126、RV3568这些带ISP和多媒体能力的瑞芯微平台时。很多人在调试音频时第一反应是查自己的代码、查ALSA配置、查麦克风接线绕了一大圈才意识到板子出厂固件里自带的那套视频推流服务早就把音频设备抓在手里不放了。今天这篇就把完整的排查思路和处理方案拆开讲清楚争取让后来的人少走点弯路。1. 现象复现与问题定性为什么录音失败先怀疑rkipc先描述一下我当时遇到的情况你看看是不是和你这边一样。我的运行环境是一块基于RV1106的第三方开发板系统镜像是官方SDK编译出来的启动后默认进入了带QT界面的demo环境。按照项目需求我需要通过ALSA接口采集本地麦克风的音频数据做语音识别相关的处理。代码本身不复杂就是标准的opensnd_pcm_open流程用arecord做测试也是一样的结果。现象非常稳定arecord -D hw:0,0 -f S16_LE -r 16000 -c 1 test.wav执行之后没有任何报错但就是不出声音数据录下来的文件全是静音而且文件大小增长极慢。如果用arecord -D hw:0,0加上-vv去跑能看到underrun频繁出现基本可以确定是PCM读取侧出了问题。改天再试试直接cat /dev/snd/pcmC0D0c一样没有数据。这种表现很容易让人误判为硬件问题我先用示波器量了麦克风偏置电压正常又换了两个不同型号的模拟麦克风还是老样子甚至一度怀疑是codec芯片虚焊差点去动BGA。后来静下心来看系统日志才发现端倪。这里的核心前提是RV1106这类带多媒体能力的芯片SDK里几乎都会默认集成一份rkipcRockchip IPC组件用来跑视频流、音频流、RTSP推流这些基础功能。该组件的设计思路是上电后自动初始化camera sensor、音频codec再启动一路后台服务。换句话说开发板一开机rkipc就已经把声卡设备占用了你的录音程序运行的时候真正能拿到的只是一个“别人用过之后剩下的壳”PCM流根本轮不到你。遇到这类问题先别急着改代码先把ps命令敲下去看看现场ps -ef | grep -i rkipc ps -ef | grep -i media只要看到类似/usr/bin/rkipc或者是LMediaServer字样的进程在跑那录音异常的源头大概率就在它。RV1106的SDK里这个进程在/oem/usr/bin/目录下通常以rkipc的名字出现有的版本里也会因为demo程序的差异叫法略有不同。我一直强调一个排查习惯遇到开发板上的外设功能不正常先查“谁在跟我抢资源”不要一上来就怀疑硬件。尤其像RV1106这种出厂固件里塞了一堆demo组件的板子软件层面的占用问题远比硬件故障更常见。2. 确认rkipc占用音频设备的完整排查链路光看到进程存在还不够动手之前要有一个完整的证据链证明音频设备确实是被它占死的而不是你自己代码的问题。2.1 先用系统工具锁定设备占用状态Linux下排查设备占用最常用的还是lsof和fuser。有些精简版根文件系统里没有装这两个工具没关系还可以用/proc接口来查。我在RV1106板上是先这样做的lsof /dev/snd/*如果提示lsof不存在直接看/proc/asound的信息cat /proc/asound/cards cat /proc/asound/pcm ls -l /proc/asound/ |然后找到占用PCM设备的进程PIDfuser -v /dev/snd/pcmC0D0c正常被rkipc占用时输出会直接告诉你PID和进程名。RV1106的音频设备节点一般是pcmC0D0cc代表capture录音通道也可能有多个声卡比如HDMI音频单独占一个card这时要根据你实际用的麦克风通道去看。如果你的文件系统里连fuser都没有那就用最原始的方式for p in $(ls /proc/ | grep -E ^[0-9]$); do ls -l /proc/$p/fd 2/dev/null | grep /dev/snd echo PID: $p done能扫到某个进程的fd指向/dev/snd下的节点那基本就实锤了。我当时扫出来的结果就是rkipc进程握着/dev/snd/pcmC0D0c和/dev/snd/controlC0两个fd。2.2 查看系统日志中的音频报错除了设备节点占用日志也会给出一些间接证据。RV1106的SDK里音频驱动用的是ALSA架构codec驱动挂在I2C总线上初始化失败或异常占用通常会在内核日志里留痕迹。查看方法很简单dmesg | grep -i codec dmesg | grep -i snd我这里的log其实没有直接说“device busy”因为rkipc初始化音频是正常的驱动层也不认为这是错误自然不会有err级别的输出。真正的线索反而是arecord执行时没有任何报错、但数据不动配合前面的fd扫描结果整个逻辑链就通了内核认为设备已经open且running第二个open操作要么被拒绝要么拿到了一个共享引用但数据流实际还是归第一个占用者。2.3 确认是rkipc自身初始化了音频为了进一步锁定rkipc内部对音频设备做了什么还可以做一个验证实验先手动停掉rkipc再跑一遍arecord。killall rkipc sleep 1 arecord -D hw:0,0 -f S16_LE -r 16000 -c 1 -d 5 test.wav如果停掉之后录音恢复正常那这个问题的定性就非常明确了。我实测下来第一次kill掉再录瞬间就出来正常波形audio数据一点问题都没有。注意有些SDK版本的rkipc可能不止一个进程父进程挂掉之后子进程会重新拉起或者被srv这类的守护机制拉起来。如果kill之后发现进程还在或者一会儿又自动出现了还得继续查守护逻辑这个后面章节会讲。3. 处理方案一临时停用rkipc保住音频调试环境如果你只是临时调试一下音频采集功能不想动固件配置那最暴力的方案就是直接杀掉rkipc进程。但这里有几个细节需要注意否则会出现“杀了又活”的循环。3.1 不同固件版本下rkipc的进程结构RV1106的SDK分好几个版本老一点的固件里rkipc是一个单进程直接kill即可新的SDK里rkipc可能派生了一堆子线程或者拆成了多个进程比如rkipc、rkipc -a这种参数形式。我先分享一个实操命令ps -ef | grep rkipc | grep -v grep拿到PID列表之后逐个killkillall rkipc如果SDK里还带了ispserver这个进程RV1106的ISP控制服务音频不归它管但保险起见对纯音频调试也可以一并观察不必一上来就杀。3.2 防止守护进程自动拉起rkipc很多板厂的SDK包里都会在/etc/init.d/下放启动脚本或者用sysvinit的Sxx脚本串行启动也有用systemd的不过RV1106一般不用完整systemd而是用busybox的init系统。所以我常建议的操作顺序是找到启动rkipc的脚本位置。常见路径是/etc/init.d/S50rkipc或者/oem/usr/bin/start_rkipc.sh。临时把这个脚本改名不让它在下次启动时自动执行mv /etc/init.d/S50rkipc /etc/init.d/S50rkipc.bak然后杀掉当前进程。这样下次重启就不会自动拉起rkipc了。不过如果你是直接在开发环境里做临时调试不想改文件系统配置那直接kill就行了重启后又恢复原样。3.3 杀完rkipc之后需要确认占用的fd全部释放杀掉进程后我建议再走一遍fd扫描确认所有/dev/snd下的节点都被释放干净。我在实际调试中遇到过进程已经kill了但某个node节点还是被其他线程占着的情况根源是rkipc会在启动时fork出多个子线程主进程死了某些子线程可能还残留。这时候可以用ps -ef | grep rkipc查完再扫描一次fd。确保干净后再跑arecord基本就能正常录音了。4. 处理方案二修改rkipc配置文件从源头关闭音频初始化杀进程只是权宜之计如果你要长期在板子上跑自己的音频采集程序每次都去手动kill不是一个体面的方案。正确做法是修改rkipc的配置让它启动时不初始化音频把音频设备让出来。4.1 rkipc配置文件结构RV1106 SDK里的rkipc配置文件一般是/oem/usr/share/rkipc/目录下的rkipc.ini或config目录里放了一堆xxx.json。找配置文件的方法是看启动参数ps -ef | grep rkipc # 注意看它的参数比如 rkipc -a /oem/usr/share/rkipc/xxx.json实际上RV1106的rkipc配置文件在SDK里通常是rkipc.ini但不同的板厂定制程度不同也用.conf或.json。我这边用的固件是/oem/usr/share/rkipc/rkipc.ini打开之后能看到类似这样的内容片段[audio] enable_audio yes sample_rate 16000 channels 1 codec_type PCM如果找不到[audio]这种段落可以搜关键字audio或者miccat /oem/usr/share/rkipc/rkipc.ini | grep -n -i audio4.2 关闭音频通道的具体改法以我的配置为例把enable_audio改成no然后重启rkipc或重启板子音频设备就不会被占用了。注意有的版本里还区分audio_in和audio_out或者叫enable_record_audio、enable_rtsp_audio需要把所有跟采集相关的开关全部关掉才能真正释放capture通道只关audio_out是不行的。改完后执行sync reboot重启完再扫一遍进程和设备占用。如果看到rkipc已经不持有/dev/snd/pcmC0D0c这个fd说明配置生效了。4.3 我的建议不要把配置文件改得太狠如果你是做音视频同步类的项目比如RTSP推流还需要带音频那把rkipc的音频全关了会导致后续要重新开启时配置比较复杂。所以我的实际建议是要么单独保留一路设备供rkipc用要么在应用层做方案调整接收rkipc已经采集好的音频数据而不是自己直接抢设备。这个思路在RV1106平台上尤其值得考虑因为芯片本身资源有限多路音频采集对CPU和内存都有消耗。与其和rkipc抢ALSA设备不如直接通过V4L2的音频扩展或rkipc的回调机制拿数据后面章节我会详细说这个思路。5. 处理方案三从设备树层面让音频独占给应用还有一种更彻底的处理方式就是修改设备树让系统里只保留一张声卡并且把这张声卡默认就留给你自己的应用层而不是让内核给rkipc的media框架也分配音频资源。5.1 为什么设备树也能干预音频占用RV1106的音频硬件链路不复杂I2S或PDM接口连接codec芯片codec挂在I2C控制总线上。设备树里会定义声卡的注册方式和dai-link。如果你在设备树里把某个音频节点status disabled那对应的PCM设备就不会注册出来rkipc自然也就初始化不了音频。但这样做的问题是你自己的程序同样也用不了那个声卡所以这个方案一般不是用来“关音频”而是用来“重新规划音频资源分配”。我见过的更合理做法是板子上如果有两路I2S接口一路I2S0给rkipc做RTSP对讲音频一路I2S1留给你自己的语音识别应用通过设备树分别挂载不同的codec或相同的codec但独立的dai-link。这样两边互不打扰。RV1106这种小封装芯片板级设计上通常只引出有限的I2S引脚很多开发板就只有一路模拟麦克风加一路I2S很难做到物理隔离。所以这个方案更多适用于定制硬件的时候提前规划好音频拓扑。5.2 怎么确认当前设备树的音频配置在RV1106的串口终端下查看当前声卡注册情况cat /proc/asound/cards如果系统里只有一张声卡rockchip,rv1106-codec说明音频路径比较简单。再查看声卡的dai-link信息cat /proc/asound/card0/pcm0c/sub0/hw_params如果需要看设备树里实际的音频节点状态可以这样ls /proc/device-tree/ | grep -i audio cat /proc/device-tree/audioff890000/status在SDK的kernel源码里对应的dts文件一般位于kernel/arch/arm/boot/dts/rv1106-evb.dts或rv1106g-evb1-v10.dts具体名字因板而异。找到音频节点后可以看到类似这样的配置i2s0 { status okay; }; acodec { status okay; rockchip,mic-type differential; };如果你的项目打算让应用独占声卡可以把rkipc配置里的音频全关同时确认设备树里声卡节点正常反过来如果你希望rkipc自己用声卡做RTSP音频推流而自己的APP通过其他方式比如直接读麦克风裸数据获取音频那就没必要动设备树。5.3 设备树修改后的编译与烧录注意点改设备树不是改一个文本就行最终生效的是dtb文件。RV1106的SDK里编译设备树通常是在内核目录下执行cd kernel make ARCHarm rv1106-evb.dtb生成的dtb文件需要替换到boot分区或resource分区不同SDK分区方式不一样有的是和kernel打包成一个boot.img有的单独放resource.img。烧录时最好用SDK提供的升级工具单独烧dtb分区不要为了省事把整个固件重新烧一遍那样容易把其他修改覆盖掉。另外我建议每次改完设备树后用fdtdump或dtc反编译一下dtb确认改动真的进去了避免因为编译缓存问题导致烧了个寂寞。6. 进阶思路绕过rkipc拿音频数据而不是抢设备前面讲的基本都是“把rkipc挪开”的思路实际上在RV1106这种平台上如果你做的项目本身就基于SDK的多媒体框架那更甜的做法是“融入它”直接用rkipc已经采好的音频数据。6.1 为什么建议尝试直接读取rkipc采集的音频流我在做这块开发时最大的感受是RV1106的CPU资源非常有限跑视频编码、ISP处理、RTSP协议栈已经占了不少负荷如果音频采集再自己开一路ALSA内存拷贝和调度开销都是叠加的。而rkipc启动时音频硬件已经初始化完成内部采集线程一直在跑数据放在共享内存或通过回调机制分发这种情况下你再开一路ALSA除了抢占设备没有什么收益。SDK里其实已经考虑到了这种需求所以在rkipc的框架里预留了一些数据获取方式。以Rockchip的MPPMedia Process Platform和RKAIQCamera IQ为例音频数据往往也走类V4L2的buffer机制。看SDK头文件里有没有类似rk_mpi_audio.h、ai_audio.h之类的接口有的话可以尝试直接初始化AIAudio Input模块绑定到rkipc已经初始化好的codec设备上。当然这种方式的学习曲线比较陡如果你完全是Linux应用开发背景不太熟悉MPP这套API那更简单的路径还是我前面说的配置rkipc不开音频自己用标准ALSA稳稳地采集。6.2 双进程协作rkipc推流自研程序录音还有一个我实际验证过可行的方案不修改rkipc的音频开关而是先让rkipc完成音频设备的初始化但不启动它的音频编解码线程。这个说法有点绕实际上是通过修改rkipc的rkipc.ini把录音编码的码率、格式配置成和你的应用一致但同时别让它跑RTSP推流音频。然后你的自研程序里用dlopen的方式加载rkipc的某个库比如librockit_adapter.so之类的调用它导出的音频数据获取接口。这么干的好处是硬件只初始化一次但数据链路是两套独立的不会互相阻塞。不过这个方案对项目架构有一定要求不太适合刚上手的朋友。我建议先把前面的基础方案跑通理解了rkipc的资源占用模型之后再回头评估要不要做这种深度集成。6.3 什么时候才真正需要改设备树设备树方案适合的场景是板子的音频硬件有不止一个输入通道比如既有模拟麦克风又有数字PDM麦克风你需要把一路分配给rkipc做监控录音另一路给你的音频算法用。或者在产品化阶段你确定完全不需要rkipc的任何功能可以在系统启动层面干净地移除整个rkipc组件连配置文件都不留。这种情况下的做法是把启动脚本里的rkipc去掉同时在rootfs的/oem/usr/bin目录下删掉对应二进制甚至把内核配置里的CONFIG_ROCKCHIP_RKIPC相关项关掉重编内核。我认为这是最干净的处理方式没有之一。前提是你确认自己的产品真的不需要RTSP、不需要视频推流只需要一套定制的音频应用。7. 几种容易出现的连带问题和稳定性注意点rkipc抢占音频设备这个问题表面上看是“设备忙”实际上牵扯到电源管理、ALSA配置、RTC唤醒、进程守护等一堆细节。我在调试过程中也踩到了各种副产品问题在这里一并分享出来。7.1 音频设备节点残留与ALSA状态锁定有时候杀掉rkipc之后用arecord依然录不了提示Device or resource busy。这通常是因为rkipc在运行时已经把声卡设置成了某种采样率、通道数驱动里的substream状态没有完全释放干净。遇到这种情况我推荐不要反复折腾用户态把声卡模块重新加载一次rmmod snd_soc_rv1106 modprobe snd_soc_rv1106如果模块已经被占用无法卸载重启板子是最快的。RV1106的开发板启动时间很短测试音频场景下重启成本可接受。7.2 rkipc杀掉后系统声音事件消失如果你是基于SDK自带的多媒体demo做二次开发系统里很多UI反馈音效、开机提示音也都依赖rkipc的音频通道。把rkipc杀了或者关闭音频之后这部分声音会全没掉。我当时就因为这个误判过“板子坏了”后来查日志才发现是rkipc被kill导致的连带效应。所以在关闭rkipc音频之前先问自己一个问题你这块板子除了录音还需要不需要播放声音如果是双向语音对讲项目那mic和speaker都需要就不能简单关闭整个音频模块得想办法让rkipc让出mic保留speaker或者干脆全部接管。7.3 看门狗与进程守护导致的rkipc复活很多RV1106板卡的SDK里会加一个简单的看门狗脚本如果检测到关键进程消失它会自动重启。表现形式就是你kill掉rkipc后几十秒它又自己回来了音频又被占了。排查方法是查看进程父PIDps -ef | grep rkipc | grep -v grep # 看PPID是不是1如果PPID是1可能是init直接管理如果PPID是某个shell脚本说明有守护进程然后查看是否存在srv、watchdog、ispserver这类辅助进程。以我的经验RV1106的SDK里有一个叫rkipc的守护脚本位置一般在/oem/usr/bin/rkipc.sh它会循环检测主程序是否退出退出了就重新拉起。如果要彻底禁止自动拉起除了改启动脚本还可能要改这个守护脚本的逻辑把循环检测去掉。这里不建议直接删文件因为你后续如果还想用视频功能恢复起来麻烦不如改成一个由你控制使能开关的版本。7.4 音频相关的内核日志噪点RV1106的音频驱动在调试阶段会频繁打印ACODEC相关寄存器读写的信息尤其在打开录音设备时。如果某个操作失败还会打acodec set volume failed之类的信息。这些日志本身不影响功能但如果你通过串口看调试信息很容易被误导。我一般会加一个过滤条件dmesg -w | grep -E codec|snd|audio|i2s这样只看音频链路相关输出不至于被其他模块的日志刷屏。正常工作时音量设置、时钟使能这类log会交替出现如果长时间没有任何音频相关输出说明驱动初始化可能没走这时回到硬件检查I2C地址对不对、codec供电正常不正常。8. 我在这类问题上的最终建议回头再看“rkipc占用音频设备”这件事本质上不是一个特别复杂的故障但它非常考验人对嵌入式Linux系统结构的整体理解。如果你看到录音失败的第一反应是去翻芯片手册那十有八九会卡壳反过来先把进程、设备节点、系统日志这三板斧用起来问题很快就能水落石出。我个人处理这类问题时的习惯是第一步永远做现场快照也就是把当前进程列表、设备节点占用、内核日志全部抓下来第二步才做干预比如kill进程或改配置第三步验证录一段音频看看波形确认资源真正释放了。这三步下来基本上能应付掉开发板上一大半的“外设不可用”类问题。从项目落地角度看RV1106这颗芯片在低成本的IPC、可视门铃、智能家居摄像头场景里很有市场而这些场景里音频采集几乎是刚需。如果你不想在开发中期被rkipc的音频占用问题绊住脚我强烈建议你在项目的需求分析阶段就把“音频设备的使用权归谁”这个决定做掉要么全权交给rkipc通过它的API拿数据要么从一开始就在配置和启动脚本层面关掉rkipc的音频把声卡完整留给自研应用。最忌讳的是摇摆不定一会儿让rkipc跑着一会儿又要自己采集最后在设备节点冲突上浪费大量时间。最后再分享一个小经验处理完rkipc占用音频设备的问题之后别忘了把你的处理过程写进项目维护文档。嵌入式板卡项目通常会有多个工程师协作你今天踩过的坑如果是靠“杀掉rkipc”这种半临时手段解决的后面接手的人很容易踩第二次。把配置文件的修改点、杀进程的命令、验证步骤记录下来对团队整体的开发效率帮助非常大。
