广州佩特电子科技有限公司

示例图片三
网站首页 > 新闻资讯 > 业界资讯

以全志H8举例电视盒子经常看到的“音频透传”以及背后的技术

2017-10-28 15:59:37 广州佩特电子科技有限公司 已读

现在市面上流行的电视盒大部分都是Android,“音频透传”是一个经常见到的词,那到底什么是音频透传、音频透传背后的技术实现到底如何,引起了我的兴趣,因此花了点时间研究了一下。由于是针对全志H8的电视盒方案进行分析,因此分析的结果不具有普遍性,可能其它的方案在技术实现上有所不同。


在开始分析前先查找了一下关于“透传”这个概念的解释,根据度娘的说法是“透传即是透明传送,即传送网络无论传输业务如何,只负责将需要传送的业务传送到目的节点,同时保证传输的质量即可,而不对传输的业务进行处理”,尽管和音频不搭界,但是基本意思就是“数据不经任何修改从发送端到达接收端”,大致可以判断音频透传也是类似的意思。


接下来看一下android中关于音频输出的一些属性定义,以及之前研究音频子系统时做的一些信息搜集和分析工作结论(基于kitkat):

1.jpg

在这些属性中,分别具有各自的特点:

DIRECT:不进行软件混音直接交HAL进行处理;

PRIMARY:软件解码、软件混音、采样率转换(SRC)什么的一个都不能少;

FAST:不进行采样率转换(SRC);

DEEP_BUFFER:原始数据就是未压缩的PCM,经处理后直接交HAL进行处理;

COMPRESS_OFFLOAD:编码数据直接交HAL进行处理(往往需要有DSP进行硬解码);

NON_BLOCKING:不如你告诉我;


下面的这张示意图表明了PRIMARY和FAST的关系(基于jellybean,kitkat大致也差不多):

2.jpg

下面的这张示意图表明了PRIMARY、FAST、DEEP_BUFFER的关系(应该是基于kitkat):


从这张图看出,DEEP_BUFFER是在例如关屏状态下播放音乐使用,而且需要HAL的支持,实际工作中我也没有遇到过这种工作方式;在这个图中,DIRECT方式并没有得到体现,和PRIMARY的差异就在于回放方式的不同,前者是通过DirectOutputThread所以无法软件混音,后者是MixerThread所以可以软件混音。


说完了音频子系统的粗略分析,现在可以来看一下度娘提供的全志H8电视盒方案的框图了:

3.jpg

4.jpg

HDMI控制器输入信号可以是视频信号组合或单独视频信号,前者的输出信号进入电视后由电视的喇叭发声,但由于电视喇叭音质的问题,可以选择后者将音频信号通过功放由音箱发声。在H8的电视盒方案中,音频PCM数据(极有可能是通过I2S)透传到AXP818进行DA转换后经功放由音箱发声,因此使用排除法后初步可以在DIRECT、DEEP_BUFFER、COMPRESS_OFFLOAD三种方式中确定一种,COMPRESS_OFFLOAD依赖于DSP的存在可以先否定,DIRECT和DEEP_BUFFER都有可能,但是基于两点考虑我认为DIRECT的可能性最大,第一,谷歌的audio_policy.conf示例中,HDMI就是使用的DIRECT方式;第二,DEEP_BUFFER比较小众,DIRECT开发和维护更容易一点。当然,音频透传是基于HDMI的DIRECT方式是因为对DEEP_BUFFER不了解的情况下做出的结论了。


广州佩特电子科技有限公司www.gzpeite.net,广州地区最优秀的全志嵌入式芯片方案公司,从事A33、A83T、A64系列芯片方案的开发!在汽车电子、嵌入式核心板、军工行业、智能家居、智能终端、物联网、穿戴设备方等行业充分的成功经验。能够为客户提供嵌入式方案选型、嵌入式产品设计开发、样板制作和包工包料等全方位的电子加工服务。


Powered by MetInfo 5.3.18 ©2008-2023 www.metinfo.cn