本文主要给大家分享一下，最近调试音频的感受！作者：飞一样的成长。
音频调试
我相信大家平时学习和开发，可能接触视频编解码会比较多，对h264和h265会比较熟悉一点！
估计大家平时接触音频的技术点会比较少，在音频技术点上，平时会遇到的技术难点，比如：回声、噪声等音质问题出现，这个相对来说会比较难解决，主要问题点首先要定位清楚，是硬件影响的还是软件影响的，或者说软件算法上可以进行优化！
这就会涉及到音频soc的移植和调试以及相关驱动编写。同时把底层采集到的原始音频数据，要经过上层的编码器进行编码和在业务上进行解码操作，在嵌入式里面，目前用的比较多的编码器标准：
- AAC
- G7xx
这里我主要以aac编码和解码来说，常见的aac编码器和解码器开源项目有：
- fdk-aac
- faac
- faad2
最近在调试音频的时候，把采集的pcm通过fdk-aac进行编码的时候，由于是第一次使用fdk-aac(交叉移植第一次到zynq平台)，在使用过程中遇到一个坑，就是fdk-aac源码里面不支持24bit的编码，目前只支持16bit，当时调试，底层只支持24bit来存储音频数据，经过编码后成aac音频文件，声音死活都是异常的，就像以前小时候看黑白电视机的声音一样！
在这次调试过程中，也熟悉了tiny-alsa和alsa的应用编程使用，当时一开始用tiny-alsa去访问声卡，以为采集的pcm也有问题，后面就使用alsa去采集，发现也是一样的问题，声音异常；最后后面才排查到是，是底层支持的24bit采样位深度，实际是32bit的，当时用命令arecord 命令录制出来的声音，通过aplay命令播放是正常的，所以就没有怀疑底层声卡的问题！
以上就是在调试音频的时候，遇到的一些问题总结！
视频和音频复合推流
前面有提到fdk-aac编码库，在调试通过获取声卡的pcm数据，然后通过fdk-aac进行编码，得到aac的音频数据，然后通过rtsp推流出去，在这个过程中遇到一个问题，就是和h264一起推流出去的时候，用ffplay拉流解码播放的时候，发现aq不断递增(音频缓存，网上说是帧长度，但是测试发现但不发送音频流的时候，aq的值会变小了，同时还可以听到声音)
这个现象显然是不对的，用ffplay解码播放，音频的音质质量是没有问题的，但是用vlc拉流播放就会出现音频卡顿的现象！
本质原因，是rtspserver这边发送的数据太快了，导致客户端那边获取到数据，解码速度没有那么快，所以就先保存到buffer里面进行缓存！
解决方法,可以让发送端发送数据稍微慢一点即可！
这个小问题点，在平时的解码器进行解码数据的时候也会遇到，比如说在公网环境下，有网络抖动，会加大数据量，也会导致解码器解码速度没有那么快，会导致一定的问题！
最后分享一点就是，通过和网友的交流，音频调试真的要非常仔细，稍微一个参数错了，声音就异常了！
好了，今天的分享就到这里了，简单记录一下音视频的问题点和解决思路，下期继续聊！
版权声明：本文内容转自互联网，本文观点仅代表作者本人。本站仅提供信息存储空间服务，所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至1393616908@qq.com 举报，一经查实，本站将立刻删除。
