OpenHarmony/harmonyOS音频框架（1）

OpenHarmony代码目录

1. base: 包含了操作系统的基础代码，如内核、库等。
2. applications: 包含了各种应用程序示例。
3. device: 包含了与硬件设备相关的驱动和适配代码。
4. docs: 包含了各种文档资料，如开发者指南、API参考等。
5. drivers: 包含了硬件驱动代码。
6. foundation: 包含了基础软件服务，如安全、IPC等。重点关注和研究。包括了音频的frrameworks和service代码
7. third_party: 包含了第三方依赖库和组件。
8. vendor: 包含了厂商定制代码。

音频架构（驱动）

Audio驱动框架（系统服务以下的模块）基于HDF驱动框架实现，包含内核态（KHDF），和用户态（UHDF）， 对北向提供音频HDI接口（类似android的hal层接口）

音频框架图

驱动架构主要由以下几部分组成。

• HDI adapter：实现Audio HAL层驱动（HDI接口适配），给Audio服务（frameworks）提供所需的音频硬件驱动能力接口。包含 Audio Manager、Audio Adapter、Audio Control、Audio Capture、Audio Render等接口对象。
• Audio Interface Lib：向下配合内核中的Audio Driver Model使用，实现音频硬件的控制、录音数据的读取、播放数据的写入，向上和上层的Audio HDI Adapter层进行对接。
• ADM（Audio Driver Model）：音频驱动框架模型，向上服务于多媒体音频子系统，向下统一接口适配各自的驱动代码。等于是对音频驱动做了再次的抽象。这个功能定位是否和alsa的功能有冲突？

音频架构（系统服务）

标准版harmonyOS音频系统代码路径（包含framwork，service）
D:\share\code\code-v3.1-Release\OpenHarmony\foundation\multimedia\audio_standard。对应图中灰色实现框着的部分。

/foundation/multimedia/audio_standard # 音频组件业务代码
├── frameworks # 框架代码
│ ├── native # 内部接口实现
│ └── js # 外部接口实现
│ └── napi # napi 外部接口实现
├── interfaces # 接口代码
│ ├── inner_api # 内部接口
│ └── kits # 外部接口
├── sa_profile # 服务配置文件
├── services # 服务代码
├── LICENSE # 证书文件
└── ohos.build # 编译文件

OH的音频服务主要有两个，audio_policy和audio_service

AudioServer::OnStart
->Publish(this) 注册服务
->pthread_create(&m_paDaemonThread, nullptr, AudioServer::paDaemonThread, nullptr) 启动pulseaudio

是否使用pulseaudio由宏PA决定，standard版本默认开启PA宏。

Audio_service关键函数解析
SetAudioParameter是Android 音频框架比较重要的一个函数，在audio_service中是个空函数，并没有设置到驱动。

调整输入输出流设备UpdateActiveDeviceRoute，这个最终也是调用到pulseaudio的sink模块。

分析audio_service代码不难发现：
9. audio_service没有audioflinger的混音功能以及音量处理等对音频数据进行处理的逻辑。
10. Audio_service的功能比audioflinger少很多

鸿蒙音频模块依赖关系

audiopolicyservice的依赖关系如下，audiopolicyservice最终调用的还是pulseaudio的接口。audio_service的依赖关系和audiopolicyservice一样。

AudioPolicyService >>> AudioAdapterManager(impl IAudioPolicyInterface) >>> pulse_audio_service_adapter_impl(impl AudioServiceAdapter) >>> src/pulse/introspect.c

数据链路。鸿蒙系统的音频播放API，audiorenderer的依赖关系如下。可见最终也是依赖pulseaudio。

audio_renderer >>> AudioStream >>> audio_service_client >>> src/pulse/stream.c

鸿蒙系统有renderersink， capturesource的概念，可以对比pulseaudio的sink和source概念。同时pulseaudio有sinkoutput和sourceinput分别可对应与鸿蒙系统的audiostream概念。

不难得出openharmony音频框架的设计思路是，基于pulseaudio框架，模仿android的音频概念进行封装和抽象。此外，鸿蒙生态的开发人员以及资料暂时相对匮乏。