海思芯片音频输出调试_专栏

一、背景描述

Hi3516C提供内置的Audio Codec，并在芯片内部对接到SIO0接口，SIO0接口只能通过内置的Audio Codec完成声音的播放及录制。在本项目中，音频模块通过调用海思的播放和录制接口来实现音频输入输出功能。目前测试发现音频输出无法听到声音，本文档通过调试解决了音频输出bug，并将调试过程整理总结，以备后续在海思+某平台上有需要用到类似调试手段。

二、问题描述

将电脑麦克风插口插入MP3播放音乐或者用标准音频连接线(3.5mm)短接电脑的麦克风与耳机插口并用电脑播放音乐，耳机插入设备的音频输出接口，通过耳机无法听到声音。同样的测试方法在别的产品上有声音，排除电脑及测试操作步骤的问题，说明沃尔玛音频输出存在问题。

三、解决方案

音频输出也即反向音频，需要设备有对讲功能采集音频流。开启设备的对讲功能，采集到音频后，将数据传输到设备，经过音频模块的相关处理后，再将数据发送给海思内置音频接口进行播放。因目前项目上网页对讲功能还未实现，故采用平台管理软件来测试。
反向音频有问题排查步骤一般有如下几点：

1、排查外围硬件问题：电脑声音是否打开，是否能正常工作；耳机麦克风等是否能正常工作
2、设备的音频输出接口是否能正常工作
3、平台管理软件的对讲功能是否能正确采集到音频流并发送到AudioManager模块
4、发送给海思播放的流能否正常播放

第一点的排查很简单，直接在电脑播放音频，能否用耳机听到声音，在调试过程中确实发现有时候会没有声音，重启电脑后声音才正常。麦克风接入的排查，用其他产品可以来验证，本调试过程中用某主流枪机产品，通过私有协议端口的demo网页测试对讲功能，能从设备输出听到声音，证明麦克风接入也是好的。

第二点的排查，需要通过海思sdk提供的音频demo程序或者本项目venc模块内置的音频调试功能来验证。

如果是通过海思sdk提供的音频demo来验证，则需要编译sdk包里的mpp/sample/audio, 并将音频编码类型改为PT_LPCM(默认是PT_ADPCMA)，编译出来的目标程序是sample_audio，将其拷贝至设备的制定目录如(/opt/mpp/sample/)，这将为后续验证本项目里的音频模块做准备，因为C音频模块编码类型也是PT_LPCM。然后执行如下命令(可查看sample_audio.c里面main函数的里说明，下面命令中23为编码类型PT_LPCM,3这是输入环接到输出，这样同时测试了设备的输入输出接口是否能正常工作)：
将耳机接入设备输出，mp3接入设备输入，可从耳机听到mp3传出的声音，则证明设备的音频输入输出都是好的。

如果是通过venc模块里的音频调试程序来验证，则需要将宏DEBUG_AUDIO打开,并移除设备里的音频模块(移除方法可通过重命名libAudioManager.so库，使其无法正常加载)，因为设备不能同时存在两个音频模块的相关处理，然后直接将mp3和耳机对应插入设备的音频输入和输出则可验证设备输入输出接口是否正常工作。

第三点的排查，则需要调试音频模块代码，如果手上有对应产品支持音频输出的也可以直接用来测试，如果能通过开启对讲，听到设备音频输出的声音，则证明SiteManager的对讲采集音频是没有任何问题的。而在调试本项目时，手上没有对应的产品，所以只能通过调试核心代码的音频模块来验证，在AudioManager.cpp的MsgClbk回调函数的videosphere::MsgType::Stream分支加入打印，看是否有音频流发送过来，当开启平台管理软件的对讲功能时，如果有打印，则证明S管理软件有采集到音频流，但目前还不能确定采集到的流是否符合格式，能否正常播放，需要进一步验证。开始时直接将AudioPlayerThreadFnc线程函数中收到的Msg的Buffer和Size抓捕写入文件中，代码如下：
在函数入口打开要写的文件

在接受消息处理处写文件(解析到Buffer和Size之后)

并用CoolEdit工具来播放，结果只听到一些噪音，起初差点断定是采集到的音频有问题，但再仔细分析代码，发现在解析流消息后，调用了DecodeAudio操作，会得到新的buffer和大小即FinalBuffer和DstSize，于是再重新写文件，将解码后的数据FinalBuffer和DstSize写进文件，用CoolEdit来播放，果然有声音出来。至此可以得出结果，SiteManager采集到的音频流是能正常播放的。

那么现在音频输出的问题就可以集中到播放过程。也就是第四点，发送给海思的流的播放过程。而要知道这个过程是否存在问题，则必须要熟悉sdk中提供的音频demo，仔细对比demo与实际程序之间对AO的设置以及发送流数据的相关处理。demo是直接读取文件，每次读取640个字节的长度发送给海思HI_MPI_ADEC_SendStream接口来播放，但Core的音频模块中是接收到一帧，就将这一帧拷贝并直接将该长度的数据发送给HI_MPI_ADEC_SendStream接口进行播放，而这个长度打印出来除了第一帧是140，后续都是1760。另外再有的主要差别是每帧的采样点数不相同，demo中每帧采样点数是320，发送数据长度是640，因为是双声道，这两者之间则必须是2倍的关系，帧长度是采样点数的两倍，这个是通过调试demo这两组数据得出的结论。但是Core的音频模块中每帧采样点数是1280，发送的长度是1760，二者之间不符合两倍的关系，因此才无法正常播放。根据sdk提供的相关文档可以发现每帧的采样点个数取值范围：G711、G726、ADPCM_DVI4 编码时取值为80、160、240、320、480；ADPCM_IMA 编码时取值为81、161、241、321、481。

静态属性，而不难发现1760=160*11,可以将每帧采样点数设置为80，发送给海思的每帧长度拆分为160，就满足了上述所要求的2倍关系，设置一个固定的变量fixPack=160,将接收到的帧拆分成每个长度为160发送给海思播放，代码如下：