企业官网建设流程全解析

一、问题背景

在完成 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

可以发现系统已经生成：

• controlC0
• pcmC0D0p
• pcmC0D0c
• timer

其中：

这一结果说明：

• ALSA 子系统已经初始化；
• PCM 播放与录音节点已经注册；
• Kernel Audio Driver 已经正常运行。

随后进一步查看声卡信息：

/proc/asound/cards

以及 PCM 注册情况：

/proc/asound/pcm

可以确认当前系统已经识别：

• ES8326 Audio Codec；
• I2S 音频接口；
• 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 Path；
• Capture MIC Path；
• ADC 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

此次测试成功启动。

说明：

最终验证结果表明：

底层音频硬件、驱动以及 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 音频底层链路的建立与问题定位，为后续实现系统级音频播放能力提供了基础。