音频透传背后的技术实现

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

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

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

typedef enum {
  AUDIO_OUTPUT_FLAG_NONE = 0x0,
  AUDIO_OUTPUT_FLAG_DIRECT = 0x1,
  AUDIO_OUTPUT_FLAG_PRIMARY = 0x2,
  AUDIO_OUTPUT_FLAG_FAST = 0x4,
  AUDIO_OUTPUT_FLAG_DEEP_BUFFER = 0x8,
  AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD = 0x10,
  AUDIO_OUTPUT_FLAG_NON_BLOCKING = 0x20
} audio_output_flags_t;

在这些属性中，分别具有各自的特点：

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