首页 > 编程知识 正文

android 播放音频,android 音频播放器

时间:2023-05-06 17:27:20 阅读:284789 作者:4449

原标题:电视盒子经常看到的“音频透传”以及背后的技术

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

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

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

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

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

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

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

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

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

NON_BLOCKING:不如你告诉我;

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

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

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

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

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不了解的情况下做出的结论了。

责任编辑:

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。