本文转载自博客:http://blog.csdn.net/qidi_huang/article/details/54020326
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
【前言】
因为这几天在为设备从 Android M 升级到 Android N 的 bringup 做准备,所以一直没写博客。趁现在刚刚把 Kernel 部分的移植做完,忙里偷闲把 2 周前解决的一个音频 UnderRun 问题记录一下,留作以后参考。
问题现象是:使用腾讯视频 APP 播放视频,一段时间后会出现 pop-click 噪音,听起来类似“哒哒”一样的声音。
【排查问题】
看到这个问题的现象后,我的第一猜测就是设备出现了 UnderRun。
大胆假设后还需小心求证。于是我在代码中开启 Verbose Log打印并重新编译系统镜像烧写到设备上。然后复现问题,并查看出现问题的时间点附近的 Log 消息。日志文件中出现了大量如下记录:
果然这是个 UnderRun 问题,Log 中的信息证实了猜想:音频播放需要 1026 帧数据,但 APP 只准备好了 1024 帧。但我们也知道,Android系统对于 underrun 出现后是有一套默认的处理流程来消除问题的,也就是紧接着的 2 条和 throttle 相关的 Log 所对应的操作。
简单介绍一下 Android 系统默认处理 underrun 问题的流程:当检测到当前写入音频数据的时间与上次出现警告的时间间隔大于预定的最大时间间隔(5纳秒)后,系统将判定音频播放过程出现了 underrun。然后系统会调用 usleep() 函数对当前 PlaybackThread 进行短时间阻塞,这样上层 APP 就能为 PlaybackThread 准备好更多音频数据。这个 usleep() 的时长是根据相邻 2 次写入音频数据的时间间隔实时计算出的。
相应的代码可以在 frameworks/av/sevices/audioflinger/Threads.cpp 中的 AudioFlinger::PlaybackThread::threadLoop() 函数中找到:
【解决问题】
前文贴出的 Log 表明,Android 系统已经检测到了 UnderRun 问题并进行了延时处理来让 APP 准备更多的音频数据。可是我们在使用腾讯视频 APP 时依然会继续发生 UnderRun 的问题,原因在于代码中计算出的延时时间对腾讯视频 APP 来说还是太短。在 Log 中我们可以看到需要的数据量为 1026 帧但实际准备好的数据为 1024 帧,所以我们可以稍微增加 usleep() 的延时时间来为 PlaybackThread 准备足够的数据。经过试验,我决定在原有延时时间上增加 3 毫秒。
重编系统镜像后烧入设备进行验证,问题得到解决。
【扩展阅读】
[1] 《音频出现Xrun(underrun或overrun)的原因与解决办法》