一、问题背景在完成 OpenHarmony 系统基础功能移植以及 GPIO、I2C、Input、USB、WiFi 等外设验证后项目进入更加复杂的系统子模块适配阶段。其中 Audio 音频子系统是 OpenHarmony 移植过程中较为复杂的一部分因为音频功能并不是单一驱动即可完成而是由多个层级共同组成Kernel ALSA ↓ HDF Audio ↓ PCM Stream ↓ DMA ↓ Codec ↓ Audio Framework ↓ 应用层播放因此音频异常并不一定意味着底层驱动不存在更多情况下是整个音频链路中的某一层没有正确连接。本阶段主要目标是确认Audio 硬件是否正常识别Codec、I2S、DMA 是否正常工作ALSA PCM 是否成功注册OpenHarmony Audio Framework 是否正确接入底层设备当前问题究竟属于驱动层还是系统框架层。在排查过程中团队针对问题现象与底层状态进行了分析并与组长沟通确认排查方向最终从“设备是否存在”的判断逐渐深入到“系统如何管理音频资源”的层面。二、确认 Kernel 音频设备状态首先从 Linux 内核音频子系统开始检查。查看系统音频设备/dev/snd可以发现系统已经生成controlC0pcmC0D0ppcmC0D0ctimer其中设备作用controlC0ALSA控制接口pcmC0D0pPlayback播放设备pcmC0D0cCapture录音设备timer音频时钟这一结果说明ALSA 子系统已经初始化PCM 播放与录音节点已经注册Kernel Audio Driver 已经正常运行。随后进一步查看声卡信息/proc/asound/cards以及 PCM 注册情况/proc/asound/pcm可以确认当前系统已经识别ES8326 Audio CodecI2S 音频接口Playback/Capture 通路。也就是说音频硬件在 Kernel 层已经完成基础连接。三、进一步确认 ASoC 音频链路为了确认 Codec 和 CPU 侧音频接口之间是否真正建立连接继续检查 ASoC 状态。通过/sys/kernel/debug/asoc/components查看当前音频组件。结果显示I2S 控制器已经注册ES8326 Codec 已加载DMA 组件正常ASoC DAI Link 已建立。同时检查/sys/kernel/debug/asoc/dais确认Audio DAI 已创建Playback 路径存在Capture 路径存在。经过这一阶段确认可以排除Codec 未识别I2C 通信失败DTS 配置错误Kernel 驱动未加载。此时可以确定底层 ALSA 音频链路已经基本打通。四、ALSA 播放能力验证完成底层确认后继续验证 ALSA 是否能够直接控制音频设备。首先检查系统中的音频工具amixer aplay speaker-test随后查看 Mixer 控件amixer scontrols可以正常看到Playback PathCapture MIC PathADC PGA Gain 等控制项。这说明Codec 控件已经注册ALSA Mixer 工作正常用户态可以访问 Codec 配置。进一步调整音频路径Playback Path Capture MIC Path ADC PGA Gain可以正常修改 Codec 参数。因此可以确认音频控制链路没有问题。五、问题定位PCM 设备被系统占用在进行实际播放测试时发现speaker-test无法正常打开 PCM 设备并提示资源占用。此时出现了一个关键判断虽然 PCM 节点存在驱动也正常但是播放设备并不能被测试程序直接访问。为了确认占用来源继续检查系统音频相关进程audio_server audio_host发现 OpenHarmony 音频服务已经启动并且正在管理底层 PCM 设备。这说明问题并不是硬件异常驱动失败Codec 无输出。而是OpenHarmony Audio Framework 已经提前占用了 ALSA PCM 资源。六、深入分析 Audio Framework 与 ALSA 关系进一步分析发现OpenHarmony 的音频架构并不是简单让应用直接访问 ALSA而是应用 ↓ Audio Framework ↓ Audio Service ↓ HDF Audio ↓ ALSA PCM ↓ Codec因此当系统服务启动后会主动管理底层音频设备。在调试过程中发现即使关闭音频相关进程系统仍然会自动重新拉起audio_server audio_host说明 OpenHarmony 服务具备自动管理机制。因此单纯关闭进程无法作为最终解决方案而需要从系统音频框架角度理解设备占用关系。这一阶段也帮助进一步明确当前音频问题已经从 Kernel 驱动层转移到了系统服务管理层。七、最终播放验证在释放 Audio Framework 对 PCM 的占用后再次进行 ALSA 测试speaker-test -D hw:0,0 -c 2 -t sine此次测试成功启动。说明模块状态ALSA PCM正常打开DMA正常I2S正常Codec正常PCM Stream正常启动音频链路打通最终验证结果表明底层音频硬件、驱动以及 PCM 数据通路均已经正常工作。八、总结本阶段围绕 OpenHarmony 在 RISC-V 平台上的 Audio 子系统展开适配验证。音频问题表面表现为无法播放但通过逐层排查发现实际问题并不在硬件驱动而是在系统音频框架与 ALSA 设备之间的资源管理关系。通过/proc/asound/cards/proc/asound/pcm/sys/kernel/debug/asoc/components/sys/kernel/debug/asoc/dais等接口确认后最终证明ES8326 Codec 已正常识别I2S 音频接口正常ASoC 链路建立DMA 通路正常PCM 设备成功注册。同时通过分析 OpenHarmony Audio Framework 对底层 PCM 的管理方式进一步明确了后续 AudioPolicy、HDF Audio Adapter 等系统层适配方向。本次工作完成了 OpenHarmony 音频底层链路的建立与问题定位为后续实现系统级音频播放能力提供了基础。