黄吉：如何适配OpenHarmony自有音频框架ADM？ 原创

编者按：在 OpenHarmony 生态发展过程中，涌现了大批优秀的代码贡献者，本专题旨在表彰贡献、分享经验，文中内容来自嘉宾访谈，不代表 OpenHarmony 工作委员会观点。

黄吉

中国科学院软件研究所

嵌入式研发工程师

OpenAtom OpenHarmony（以下简称“OpenHarmony”）正在蓬勃发展，但开源社区在国内还是一个年轻的新生事物，如何参与社区开源贡献已经成为开发者们越来越关心的话题。

中国科学院软件研究所的黄吉老师，将以一个开发者的视角给大家阐述深度参与到 OpenHarmony 社区的一些心得体会。

Q=OpenHarmony A=黄吉

Q1：请简要介绍下自己，以及所在开发团队

大家好，我叫黄吉，目前就职于中国科学院软件研究所（以下简称“中科院软件所”），在中科院软件所负责 OpenHarmony 移植开发相关工作。中科院软件所团队在 OpenHarmony 项目组中主要负责 OpenHarmony 的技术研发、技术支持、社区支持、SIG 仓 CI 门禁支持及维护、活动营销支撑、及其他社区治理相关的工作。

Q2：作为开发领域知名的技术大牛，您最初为什么会选择加入OpenHarmony生态、参与开源共建呢？您认为，OpenHarmony项目最吸引人的点在哪里？

大牛谈不上，我的技术能力、专业认识等各方面需要学习的地方还有很多。

我认为这个选择是双向的，一方面我被 OpenHarmony 项目积极的开源精神深深吸引，感觉为开源社区贡献代码真的是一件很酷的事情，内心有参与 OpenHarmony 生态的主观动力；另一方面是 OpenHarmony 社区秉持开放包容的宗旨，接纳了很多普通开发者，我才会有机会去了解 OpenHarmony 项目并尝试为其贡献代码。

开源共建也是 OpenHarmony 项目最吸引人的重要特点。现如今 OpenHarmony 项目为国内开源之路迈出了坚实的一步，这条路可能走得没那么快，但它确实勇敢地踏出了脚步，这就足够了。

Q3：您在什么时候加入了OpenHarmony开源项目团队？通过多久研发了RK3568的ADM驱动，合入主干上千行代码，现在被评为代码月度贡献之星，真的太了不起了！您方便给我们介绍一下这个产品吗，或者这段经历吗？这么短时间达成了这样好的效果，请问您的“秘诀”都有哪些呢？

我是在 2021 年 2 月份的时候加入 OpenHarmony 开源项目团队的。当时的 OpenHarmony 还只有轻量及小型系统，如今标准型系统的能力已经趋于完善了，并且有了自己的 hap 应用开发工具。可以看到 OpenHarmony 的能力是在不断快速迭代、演进及完善。

回首 Dayu200 开发板的 ADM(Audio Device Model，音频设备模型)开发过程，是充满喜悦、充满收获的。ADM 是 HDF(OpenHarmony Driver Foundation)下面的一个音频子模块，ADM 已经支持了 Hi3516DV300 等开发板，而我们做的这块就是对 Dayu200 开发板的适配。

在我们做适配之前，音频驱动完全依赖于 TinyALSA 库，现在将其完全 HDF 化，不仅解决了依赖问题，还具有里程碑意义，为其他第三方开发板的移植提供了参考。适配过程中，我们发现从零开始实现接口是不现实的，造轮子不仅需要考虑稳定性、音频编解码、格式匹配、DMA 传输等多方面的东西，而且工作量巨大，也不利于后续的维护。

因此我们另辟蹊径，采用 Linux 原生函数来进行适配，其中 Codec 层通过注册 RK809 原生对象来获取操作 I2C 总线的对象，然后传入对应的 regmap 函数来进行寄存器读写操作；DAI 层通过注册 RK3568 原生对象来获取操作 I2S 总线的对象，然后传入对应的 regmap 函数来进行 I2S 寄存器读写操作；而 DMA 部分则是通过 Linux原生的 dma_engine 相关函数，按照规范的流程来完成请求 DMA 通道，配置 DMA 通道，预处理 DMA 通道，DMA 数据提交，DMA 数据处理等一系列的操作。

因为厂商一般都会对内核部分进行维护，并且其硬件外设都由内核驱动进行管理，使用 Linux 原生接口就相当于搭了一座桥，把上层框架与内核驱动联系了起来，维护起来更容易了。同时，这种适配思路和方法是独创性的，是十分具有借鉴意义的。

如果说有什么秘诀的话，那就是一往无前的勇气、不屈不挠的毅力以及永无止境的求知欲。遇到问题是再寻常不过的事情了，“长风破浪会有时，直挂云帆济沧海”，唯有迎难而上方可解决难题。有时候很可能多条路都走不通，有时候会有挫败感，但坚持的毅力会带我们走出去，慢慢找到新的方向。当然，还有很多东西是没接触过或者不甚了解的，但求知欲会推着我们前进，推着我们主动去学习，去了解未知，去向身边的人求教，最终帮助我们的成长。

Q4：能开发出这么一个优秀的产品，将核心代码合入主干，您和您的团队一定付出了很多。可以给我们分享一下，开发这个产品的整个过程，包括前期、中期、后期，您们具体都做了哪些工作，投入了多少人力和资源？

Dayu200 开发板基于 OpenHarmony 的移植工作是由润和软件主导，社区的多家成员单位的同事深度参与其中，有华为、润和软件、深开鸿、中科院软件所等。中科院软件所团队承接了移植 ADM 模块的任务 。

接下任务后，我们联系到了华为和润和软件的技术人员，获取到了目标开发板的芯片、原理图等研发必要的资料，随后熟悉硬件的参数设计、芯片寄存器配置等信息，并且逐渐搭建代码框架。熟悉过程其实花费的时间和精力非常多，对于完全不清楚的结构，需要一点一点阅读文档，遇到不清楚的细节问题，还要联系开发人员一点一点对齐，这是一个考验耐心的过程。

中科院软件所团队在整个开发过程中一直与其他各单位同事保持着紧密的沟通，几乎每天都会组织会议一起讨论研发方案，针对使用 HDI 的读写接口无法作用于目标芯片的问题，选择采用 Linux 原生函数来进行适配解决，有效提升了进度。

在完成了代码的初步功能并验证后，我们把本地适配好的代码上传提交到 OpenHarmony 代码仓，期间还经过了 CI 门禁的代码编译、代码测试、代码规范审查，有问题的部分会被修改直到通过审核。其中这个过程也相当考量细节，有可能代码规范审查一下子就报几百个规范问题或者警告，包括空格规范问题、换行规范问题、注释规范问题、宏定义规范问题等问题，需要仔细地核对修改。最后经过对代码的不断修正和验证并将代码整理到符合社区规范的状态后，这些代码成功合入到了主干。

总的来说，这是各方一起通力合作的结果，完成了从进度跟踪到任务分配再到技术问题攻坚的一系列问题的闭环。

Q5：在整个开发进程中，您和您的团队遇到过哪些技术上或其他方面的难题？这些难题又是如何被逐一解决？在这些难题被解决的过程中，您总结了哪些宝贵的经验or教训？

整个开发过程中主要有以下几个困难点。

第一，Dayu200 开发板的音频芯片比较特殊，它包含 Codec、RTC、PMIC 等多种功能，不能简单的采用 ADM 接口去操作它。为了避免影响到其他功能的正常运作，我们使用了原生 Linux 设备驱动接口来操作 I2C、I2S、DMA 的通信以及数据传递，避免了异常操作的风险。

第二，播放一段时间后，停止播放，持续有尖锐的很小的声音。针对此问题，我们注册了 Trigger 函数，根据接收到状态信息，如果为停止状态，则对 Codec 相关器件进行下电。

第三，RK 的音量调节功能必须要给左右声道寄存器写入相同数值才可生效，但当时框架还不支持对左右寄存器的赋值。后来，我们与框架开发人员协商，使得框架新增了该项功能，最终适配上了音量调节能力。

经验的话，就是一定要多去和不同的技术开发人员沟通交流，有时候可能会陷入思维定势，常常不能发现自己代码上的问题，而别人一眼就看到关键所在，直接指出来，那么问题就迎刃而解了。

Q6：加入OpenHarmony生态以来，您最大的惊喜是什么？或者有哪些具体的收获？

加入 OpenHarmony 生态以来，我最大的惊喜是了解了开源社区的玩法。在 OpenHarmony 社区，可以从别人的代码中学到更多知识，同时自己的代码可以被更多人看到，好的地方不好的地方，都会有人提出来，在这种快速的反馈中，更能够了解自己存在的不足。

我认为，这段时间充满了收获，首先是认识了很多志同道合的小伙伴，大家都积极参与开源项目，贡献自己的代码，开源之路本就荆棘丛生，有这么多开源社区的伙伴一起前行，路也好走了许多。其次是获得了磨练与成长，在优秀的人面前，你能看到差距，从而去学习别人的优点；在优秀的代码面前，你能看到框架构思的差距，从而去学习别人的编码思路，这确实让人受益匪浅。 

Q7：期待未来OpenHarmony哪些方面能够得到改善、提供更多支持？

客观的说，OpenHarmony 还存在有一些不足的地方，比如社区反映的入门资料较少、框架解析资料不够清晰、issue 请求响应不太及时等问题。

主要原因在这么几个方面：一是 OpenHarmony 发展初期，它是国内最前沿的大规模的开源系统，它的发展是摸着石头过河的过程，必然会存在这样或者那样的没有遇到过的问题，这是相当正常的；

二是开发者技术水平和技术关注点存在差异，有的开发者可能需要更详尽的入门资料来进入门槛，有的开发者可能关注底层驱动lib库的编译生成方式，有的开发者可能关注 OpenHarmony SDK 如何生成 hap 应用，不知道如何找到自己想要的开发资料；

三是 OpenHarmony 每个代码仓的管理相对独立，由每个仓库自己的 committer 进行管理，一方面很多开发者可能找不到正确的代码仓来提 issue，另外一方面某些 committer 可能由于事务繁忙，没有及时地回复 issue。

我期待未来 OpenHarmony 能够切实的引导开发者，根据他们的需求，提供对应的开发资料开发资源，并且能够进一步加强与开发者的联系，更多倾听开发者的声音，给予良性的有效的反馈。

Q8：OpenHarmony目前仍处在开发探索阶段，很多共建单位和生态伙伴还不清楚开源项目的玩法，或不知该如何着手进行开发。可以请您给大家分享一条，您认为最重要或最值得分享的心得吗？

我认为 OpenHarmony 是一个非常自由开放的项目，各家共建单位或生态伙伴可以根据自己的需求想法来进行选择。

如果想进行应用hap开发，可以参考 OpenHarmony 的 docs 仓下面的 JS 开发资料。如果是想进行开发板移植，可以参考 OpenHarmony 的 docs 仓下面的芯片移植资料，在此基础上，如果想贡献代码，则可以联系 OpenHarmony SIG 相关组织走代码上仓的流程。

至于开发上的问题，建议在 OpenHarmony 社区的 Zulip 上提问（https://zulip.openharmony.cn，未注册用户需要邮箱注册），或者在研发讨论群里面提问，或者是在相关代码仓提 issue，总之，渠道是十分广泛的。

• JS开发资料：​​https://gitee.com/openharmony/docs/tree/master/zh-cn/application-dev/reference/apis​​
• 芯片移植资料：​​https://gitee.com/openharmony/docs/tree/master/zh-cn/device-dev/porting​​

Q9：开放性问题，可以畅所欲言，请问您还有什么想告诉大家？

OpenHarmony 的发展是一个任重而道远的过程，现在的 OpenHarmony 就像一个刚刚学会走路的小孩，但它的成长还需要相当长的一段时间，它的成长需要有人去引导。

OpenHarmony 开源社区的发展离不开广大开发者的支持，离不开广大媒体的支持，离不开国内外各大共建单位以及生态伙伴的加入。

我非常希望大家能够更多关注 OpenHarmony，多给社区提提意见，大家的声音才是 OpenHarmony 健康发展的动力，同时希望大家多给 OpenHarmony 提交代码，即便一砖一瓦一沙一石，汇聚起来都可以是伟大的力量，相信只要大家的努力汇集起来，OpenHarmony 一定能够向着积极的方向发展。