江苏龙网

  1. 首页 > 人文 > >

「音箱」RT-Thread智能音箱音频应用实践( 二 )


「音箱」RT-Thread智能音箱音频应用实践
本文插图
如上图 ， 我们从四个方面做了对比 。 如大家所知 ， Linux所需的RAM、Flash是比较高的 。 ARM cortex-A方案是主流高端方案需要32MB RAM 和64MB Flash 的消耗 。 据我们统计 ， 迁移 RTOS 方案 后可做到2MB RAM 和 4MB Flash 左右的消耗 。 由于 RTOS 系统比较轻巧 ， 我们可以使用更小的RAM、Flash 芯片 。

「音箱」RT-Thread智能音箱音频应用实践
本文插图
除了以上优势 ， RTOS也有生态劣势 。 智能音箱的操作系统更需要涉及到网络、音频相关的内容 。 Linux系统有成熟稳定的网络框架、音频子系统以及ffmpeg、Curl等开源软件 。 RTOS调度器则更多的使用了轻量级网络协议栈 ， 在音频方面比较空缺 ， 公司各有私有的方案 ， 成本比较高 。
「音箱」RT-Thread智能音箱音频应用实践
本文插图
我们使用RTOS研发音频播放系统鉴于成本趋势、系统资源问题和开发成本的综合考虑 ， 希望能完成一套比较完整成熟的音频系统 。
RT-Thread 网络音频播放器设计的迭代
「音箱」RT-Thread智能音箱音频应用实践
本文插图
如上图是我们第一版音频播放器方案框架 。 早期设计这一款播放器 ， 没有考虑网络播放的相关的功能 。 这版逻辑比较简单：获取音频数据后直接做解码 ， 解码过程是一个循环逻辑 ， 单线程等待外部响应事件 ， 包括seek事件、暂停恢复事件、停止事件完成播放器逻辑 ， 最后将解析出的数据写入底层音频驱动 。
「音箱」RT-Thread智能音箱音频应用实践
本文插图
由于第一版不满足网络播放的市场需求 ， 我们将网络组件、网络功能添加到了系统中 。 如上图中红色逻辑处理部分 。 在这部分我们对框架思路做了修改 ， 将文件、网络资源放到同一层 ， 选择本地或网络下载音频资源 ， 整体呈单线程模式 。 无论打开的URL资源是本地资源还是网络资源 ， 都是获得资源后做解码播放。

「音箱」RT-Thread智能音箱音频应用实践
本文插图
这版播放器随着在项目中越来越多的使用 ， 逐渐的出现了很多噪音卡顿拖慢等问题 。 如上图是我们PCM项目回采得出的数据分析结果 。 我们在播放音频出现了短暂噪音之后继续播放的情况 ， 后期多方面分析发现 ， 这是由于网络情况不稳定 ， 解码器短暂接收不到数据造成的 。
「音箱」RT-Thread智能音箱音频应用实践
本文插图
如上图所示网络不可靠的原因有多种 ， 很多网络不稳定是网络硬件造成的波动 ， 软件层面是无法完全避免的 ， 我们只能通过软件算法和思路减少这些问题造成的影响 。
「音箱」RT-Thread智能音箱音频应用实践
本文插图
如上图是我们第三版改进后的播放器框架图 。 左侧是一样的 ， 依然是获取数据进行解码 ， 唯一不同的是我会从网络缓存区获取数据 。 启动播放后 ， 我们会启动一个新线程将本地数据或网络音频写入缓存区 ， 将下载与解码器分离 。 只要缓存区有数据 ， 解码播放便不会出现卡顿 。
「音箱」RT-Thread智能音箱音频应用实践
本文插图
我们采用了带RTOS 唤醒调度机制且具有水位线管理的 pipe 作为第三版的音频缓冲区。 例如我们设置了一个512KB的缓存区 ， 通过HTTP连接下载数据 。 如果缓存区中没有数据 ， 我们可以简单认为下载与解码同时进行的 。 解码时缓存区没有数据时会等待直到音频数据高于水位线 。 水位线即可开始解码的最低缓存数据量 。 我们做了一个可动态调节的水位线机制 。


推荐阅读


上一篇：『乐高积木』最新研究：乐高积木可在海洋中存留1300年

下一篇：「美好，一直在身边」擎创科技完成千万美元级B+轮融资，加大码力研发核心算法