Openharmony4.0的音频模块调用关系图如下：

如果你想播放或者采集音频，可以通过图中描述的四种方法：

1. OHAudio：openHarmony audio框架提供的API，OHAudio会再调用pauseaudio，pauseaudio再调用alsa；OHAudio API 中有RTC关心的路由（music或者voice communication）和延时的配置

2. OpenSles：openHarmony audio框架提供的API，OpenSles会再调用pauseaudio，pauseaudio再调用alsa，OpenSles API没有对路由和延时的配置，估计以后版本也不会添加，因为我认为框架的设计者会把重心放在OHAudio上面，至于OpenSles就放放吧：）（个人观点）

3. 应用程序直接调用pauseaudio API，pauseaudio再调用alsa

4. 应用程序直接调用alsa lib

（pauseaudio是一个CS模型的音频框架，很多终端上使用，网上的资料很多，这里不再累述）

有朋友就会问：这么多，我应该用哪一种啊？头大！

我的回答，it depends

      A. 如果你只是播放某个音乐文件或者录制麦克风音频到本地文件，建议你直接用方法1或者2，这两种方法的API简单明了，上手快

      B. 如果你要开发音视频通话应用，对性能和端到端延时的要求没那么苛刻，可以使用方法1和方法3：方法1是Openharmony提供的API，已经有了对部分RTC场景的配置功能，使用较为简单；而方法3需要需要修改一些pauseaudio的配置，复杂一些。

     C. 如果你要开发RTC应用，对性能和延时的要求很高，只能使用方法4（需要修改audio框架代码）：

通过实测发现Openharmony的pauseaudio对CPU的消耗较高（远远大大于androd上面的audioflinger，我是通过在同一硬件终端上刷不同的两种镜像对比出来的，Android11和Openharmony4.0），而且为了让应用和底层的alsa驱动比较好的衔接（采集的时候不会出现应用来不及采集，播放的时候应用来不及填充数据，导致采集或播放的音频数据有失真），pauseaudio在对alas-lib的使用的时候往往配置比较大的缓冲区（带来比较大的延时），这点大家可以详细研究alsa缓存区的原理；

具体怎么做呢？

   C.1.修改audio框架中的相关代码，使得系统中只要没有使用pauseaudio服务，pauseaudio立即释放对音频设备（因为pauseaudio默认是独占音频设备的）

   C.2. 基于alsa-lib 开发我们采集和播放逻辑，其中最重要的是有两点：

          a. 为了低延时配置alsa播放和采集缓冲区

          b. 当我们不在使用音频设备的时候，一定要释放音频设备

结果：

1. 在低性能低成本终端上，我们采用的方法4，由于减掉pauseaudio框架，CPU降低了很多

2. 由于直接设置较低的alsa缓冲区，端到端的延时也降低了很多

3. RTC对音频设备的使用和Openharmony框架对音频设备的使用互不干扰，逻辑相互独立

方案4其实也有不足的地方，这个留给读者去思考，这些不足需要额外的工作去弥补，和收益相比，这些不足就显得微不足道了。

感谢陈杰对此文有贡献