问题场景:在起播和切换清晰度时,音频有杂音。问题分析:音频效果类问题(杂音、爆破音、卡顿等)通过hilog往往难以分析,一般是逐层抓取PCM数据和Trace进行分析。步骤一:通过抓取复现问题的PCM发现确实存在问题:发现在调用开始时获取的音频流数据不够,没有达到audiorender回调上来的bufferlength长度,然后memset空的数据给到系统层了。所以导致就有了杂音,这是应用层给的数据就有问题。解决方法:应用层做判断,数据达到audiorender回调上来的bufferlength后再做拷贝给过去,避免把空数据给到系统层。步骤二:按上述方法修改后解决了起播杂音的问题,但是发现从1080P切换到HDR时,偶现有轻微杂音。通过抓取复现问题的Trace发现确实存在问题:回调onwritedata中获取到第一帧数据后,中间等了400ms,才开始接收到第二帧数据。原因是应用层在处理的时候会等待视频数据传输过来后再把音频数据同步给过来,这里经过开发分析,阻塞时间太长,可能会存在问题。解决方法:应用层通过处理降低了写数据帧阻塞的时间。
问题场景:
在起播和切换清晰度时,音频有杂音。
问题分析:
音频效果类问题(杂音、爆破音、卡顿等)通过hilog往往难以分析,一般是逐层抓取PCM数据和Trace进行分析。
步骤一:
通过抓取复现问题的PCM发现确实存在问题:
发现在调用开始时获取的音频流数据不够,没有达到audiorender回调上来的bufferlength长度,然后memset空的数据给到系统层了。所以导致就有了杂音,这是应用层给的数据就有问题。
解决方法:
应用层做判断,数据达到audiorender回调上来的bufferlength后再做拷贝给过去,避免把空数据给到系统层。
步骤二:
按上述方法修改后解决了起播杂音的问题,但是发现从1080P切换到HDR时,偶现有轻微杂音。
通过抓取复现问题的Trace发现确实存在问题:
回调onwritedata中获取到第一帧数据后,中间等了400ms,才开始接收到第二帧数据。原因是应用层在处理的时候会等待视频数据传输过来后再把音频数据同步给过来,这里经过开发分析,阻塞时间太长,可能会存在问题。
解决方法:
应用层通过处理降低了写数据帧阻塞的时间。