赵海鹏:如何进行 OpenHarmony 音频特性架构设计和开发工作 原创

发布于 2022-5-11 10:13
浏览
0收藏

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

 

赵海鹏:如何进行 OpenHarmony 音频特性架构设计和开发工作-开源基础软件社区赵海鹏

江苏润和软件股份有限公司

资深软件开发工程师

 

本期 OpenAtom OpenHarmony(以下简称“OpenHarmony”)开发者故事,我们特别采访了 2 月代码最佳贡献者、一位接触 OpenHarmony 1 年左右,2022 年初便完成高难度开发项目的开发者——润和软件资深软件开发工程师赵海鹏。


赵海鹏是润和 OpenHarmony 南向业务媒体领域负责人,主要承担 Audio 开发工作。在 RK3568 平台 Audio Driver Model 适配开发过程中,在突遇西安疫情的情况下,硬件和沟通问题都面临巨大的挑战,面对急迫性的项目需求,赵海鹏和他的伙伴迎难而上,通过各种渠道去协调设备,把做好的固件寄送出去,协调软件所的伙伴们做远程测试,包括焊接等等,几乎每天在线工作及沟通 12 个小时以上,最终克服困难圆满完成任务。


我们与赵海鹏一起聊了他加入 OpenHarmony 生态的初心、对 OpenHarmony 架构适配的理解、工作中遇到的难题和攻克的过程、以及开源过程的心得与教训等话题。现将专访内容整理如下,希望对你有所启发。

 

赵海鹏:如何进行 OpenHarmony 音频特性架构设计和开发工作-开源基础软件社区Q=OpenHarmony A=赵海鹏


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


大家好,我是润和软件资深软件开发工程师赵海鹏。我从 2020 年 10 月份开始正式接触 OpenHarmony 开源项目,开始了解框架和结构。目前在润和软件主要负责 OpenHarmony 南向业务媒体领域。

 

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

 

第一个层面,从大的环境来说,OpenHarmony 是创新的操作系统,这是吸引我的首要因素。

 

第二个层面,从个人成长来说,我希望在 OpenHarmony 发展的初期加入进来,这样会让我对整个系统框架的演变更为清楚,个人的成长机会点相对比较多。

 

Q3:您方便给我们介绍一下这个产品吗,或者这段经历吗?这么短时间达成了这样好的效果,请问您的“秘诀”都有哪些呢?

 

"秘诀"谈不上,主要学习和工作过程中,多给自己提问题,带着问题去学习与研究;同时,针对过程遇到问题不断总结与积累,形成知识库。

 

我接着说一下主要贡献的特性。我们目标是,把社区上非海思芯片第三方平台 RK3568 的 Audio 驱动适配起来。因为 Openharmony Audio 驱动框架是 ADM,原生的驱动是 ALSA,差异相对来说比较大。为了加快进度协调软件所的一个伙伴和我一起联合开发,正好赶上西安的疫情,我就一直在家里专注的搞研发,需要交流就通过线上沟通。过程中会遇到很多困难,调试 Audio 驱动,需要一些硬件设备(示波器、逻辑分析仪等)的支撑,而处在疫情环境下,有的设备是缺少的,西安的快递也很难进来,我们通过各种渠道去协调设备,然后把做好的固件发出去,让中科院软件所的伙伴做远程测试,包括焊接等等。

 

另外,我们任务的时间节点比较紧张,只有不到一个月左右的时间,Audio 驱动代码裁剪过后还有三万行,也就是我们要把三万代码读懂再适配到 OpenHarmony 上,给我们的工作也增加了难度,但是我们都一一克服,坚挺过来,最终完成了任务。

 

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

 

在前期,内核代码中 Audio 相关的有 10w+ 的代码,需要做裁剪成最小集合,另外,需要梳理主线上 ADM 的代码框架,参考:https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/driver-peripherals-audio-des.md

 

中间阶段,进入真正的开发过程中,我先把框架做好,然后按照模块分工合作开发。当时因为是线上办公,每天的工作时间都在 12 小时以上,双方通过线上会议交流,出现问题及时沟通及时解决。

 

后期主要是调试阶段,当时信号有一些问题,中科院软件所的硬件工程师帮我们焊接,然后采样并把信号图像回传到我们这边,再做分析,然后再做下一个方案的调整,遇到一些难以解决的问题,也会求助 ADM 框架负责人。为了保证较高的工作效率,这些都在线上会议进行沟通。

 

另外,调试过程中发现框架存在一些不友好不完善的地方,在适配过程中不断完善,形成了 Linux 相对简单适配的方案并形成文档,在社区上发布。该方案存在的问题是不兼容 LiteOS,没有完全实现 ADM 的优化能力。

 

赵海鹏:如何进行 OpenHarmony 音频特性架构设计和开发工作-开源基础软件社区

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

 

技术问题:RK3568 平台的 codec 组件使用的 RK809,此芯片不是单一的 Codec 功能还包含电源管理的模块,使用同一路 I2C 控制通道,拆分难度大,可能还要设计电源管理模块。

 

解决方案:借助 Linux 原生驱动,ADM 的驱动接口初始化节点调用对应的 probe 函数,按照此思路触类旁通,其余模块也按照的这样的操作,减少驱动代码开发对寄存器的依赖,提升开发效率。具体的方案在 RK3568 驱动适配文档中有说明,请关注。

 

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

 

收获的第一个层面,是我以前的工作经历相对来说是单个模块或者单个特性,而现在有机会面对整个系统。同时,OpenHarmony 正经历从 0 到 1 的过程,在我们工作的过程中可以深入了解整个系统,获得比较全面的认知,对能力的提升空间比较大。

 

第二层面针对系统的设计,以前我只需要考虑需求内部实现逻辑、流程、接口等。现在做需求设计的时候,先考虑外部依赖,定义接口,然后再去设计具体的需求的框架,软件分层等等。

 

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

 

我觉得最主要的是结合自己过往的工作背景或者环境,如果没有太多经验,可以从 mini system 入手,如果有一些安卓或者 Linux 的经验,可以从 standard system 入手。总之,一定要从自己熟悉的模块入手,这样才能触类旁通,通过边学边拆的方式,熟悉度才会越来越高。

 

入手之后,需要集中在单点上深入研究,把一个点深度了解后,其他点学习的就会比较快。同时也要看看整体的架构,如果对架构都不了解的话,是不足以支撑后续开发和项目工作,至少需要有概念性的认知。

 

Q8:开放性问题,可以畅所欲言,请问您还有话想告诉大家?

 

从驱动系统上来讲,目前 OpenHarmony 的驱动是基于 HDF 开发的,既可以在 Linux 上运行,也可以在 LiteOS 上运行,便于移植。但目前成熟度不够,适配难度较高。对开发者来说不太友好,希望各共建单位和开源开发者一起去完善,让平台驱动适配更容易。

 

 

赵海鹏:如何进行 OpenHarmony 音频特性架构设计和开发工作-开源基础软件社区

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
2
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐