openharmony有多种音频调试方案，这里介绍和解读一下openharmony的音频方案。

一、参考文档

根据openharmony在社区分享的文章《audio适配方案》，我们可以知道对于openharmony系统适配音频有四种方案，分别如下：

adm驱动适配
alsalib适配标准alsa
hdi to hidl对接
hdi对接vender hal
对于上面四种方案，我相信大部分人第一次看到会有点犯懵，所以这里主要解释一下这四种方案的具体意思。从而理解openharmony是如何处理音频的。这四种方案的图示如下：

二、ADM适配方法

ADM的全称是audio driver mode，这是openharmony系统自身的一套音频框架，它仿照alsa的基本概念做了改造和裁剪，其基本思想还是基于alsa。所以如下

对比于alsa，如下

所以我们可以知道

ADM的的实现如下：


platform-----dai-----codec

这里platform实现了平台dma/cpu的驱动，dai实现了i2s的驱动，codec实现了具体声卡的驱动

alsa的实现如下：


platform-----dai-----codec

这里platform实现了平台dma/cpu的驱动，dai实现了i2s的驱动，codec实现了具体声卡的驱动

可以发现ADM的本质和ASoC完全相同，但如果我不解释，光看图，或许以为ADM与ASoC不太一致。

其主要原因是openharmony的框架图中，故意模糊了概念，而ASoC的框架更清晰能够一眼看懂

至于其他的，也大同小异

alsa的machine对比于ADM的card manager
alsa的dapm对于于ADM的sapm
alsa的controls对比ADM的control dispatch
alsa的pcm interface对比于ADM的stream dispatch

2.1 ADM我们需要做什么

根据上面的分析，我们可以知道ADM是改造的ALSA，所以对于ADM的开发，我们需要遵循ADM的框架，编写HDF driver，实现Codec驱动即可

三、alsa适配方法

对于alsa而言，驱动可以完全使用标准linux的ASoC框架，上层则配置使能alsalib即可，对于openharmony，根据其系统的设计，我们还需要适配openharmony的上层支撑，这里是supportlib的实现。

所以关键点有三个，如下：

3.1 内核走标准alsa


CONFIG_SOUND=y
CONFIG_SND=y

# CONFIG_DRIVERS_HDF_AUDIO is not set
# CONFIG_DRIVERS_HDF_AUDIO_RK3568 is not set

3.2 内核调用库走alsalib

通过配置项drivers_peripheral_audio_feature_alsa_lib来控制代码的执行逻辑，如果是drivers_peripheral_audio_feature_alsa_lib=true，则默认使用alsalib的libasound库

具体代码路径如下：


drivers/peripheral/audio/hdi_service

3.3 系统调用库走alsa的实现

根据上面的方法，已经可以确保系统的音频走alsalib的libasound的了，但是openharmony系统需要能够使用音频，需要对音频的api做一下重实现，这里已经完成了，就是supportlibs，代码仓库位置如下：


drivers/peripheral/audio/supportlibs

这里文件情况如下：


adm_adapter  alsa_adapter  interfaces

可以知道，对于ADM，默认走adm_adapter，而对于alsa我们走的是alsa_adapter，其中interfaces对上层的抽象，提供了上层需要的api接口

对于上层需要的接口，简单介绍如下：

至此，openharmony走alsa的理论路径如下（自下向上）：


ASoC---->libasound---->supportlibs(alsa_adapter)--→openharmony api

四、hdi to hidl方案

如果不太熟悉android的同学，我们在提到hidl，会不太清楚，再者，在《audio适配方案》中，里面描述的是HDIL，这个东西没有任何的解释，所以我认为这是华为的人编写文档的时候的一个书写错误，习以为常就好啦。

这里提到的hidl是借鉴了安卓的思路，安卓在对于应用层之间，使用aidl，在对于设备抽象层之间，使用hidl。对于安卓，其实现方式如下（自上到下）：


SystemApp--->Android Framework ---> HIDL Binder--->HIDL Service Manager----> HAL

所以openharmony也在借鉴安卓的思路，实现自己的hidl，故我们可以看到如下言论

对于openharmony的idl，对于文档如下：


https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/IDL/idl-guidelines.md

目前实现的是应用和服务之间的通信方案，对比于安卓的aidl。

所以可以通过查找代码，根据audio的实现可以知道，如果需要实现hidl，则需要实现hidl的服务，类比于安卓的hidl service manager。该仓库应该在


drivers/peripheral/codec/hal/idl_service

但是目前看来，没有良好的实现和落地，还需要进一步发展。此方案不容易落地。未来可能是openharmony努力的目标。

五、hdi对接vendor hal方案

此方案的意图在于OEM自行根据HDI的接口自己实现，哪有一个操作系统说我提供上层api，下层自己实现的说法，故不现实。

根据此说法，应该实现路径如下（自低到上）：


alsa/自己实现audio框架（openharmony不干）--->自己实现vendor hal（openharmony不干）--->vendor hal对接hdi api（openharmony上层api）

如果底层使用alsa，则第三章的方案中的alsalib和supportlibs需要自行实现成vendor hal，所以这属于一个异想天开的方案，当前阶段不必理会。

目录