|
/**
* @author wangdaopo
* @email 3168270295@qq.com
*/
影响音频质量和稳定性的因素
音质好坏的评价，响度、音高、音色，
测试，你的语音引擎是基本可用的，客观评测软件是RMAA（RightMark Audio Analyzer；比较适合开发者自己去做，在上线前自测的一些方法
频率与音色的听音训练 及 训练音乐听觉
语音通信中提高音质的方法
音频软件开发中的debug方法和工具
-
影响音频质量和稳定性的因素到底有哪些 实时语音到底有哪些特征？
0.通话中语音信息丢失了，这个对话是根本不能继续下去的
1.网络随机性（丢包 延时 抖动）：都会导致听感滞后或者断续；网络对音频质量的影响是非常直观的，如果承载音频信息的语音包在网络传输的过程中丢失，晚到，或者不均匀的到，就会造成我们常说的丢包，延时和抖动。另外值得一提的是，除了在传输层引起的丢包抖动，最后一公里(Last Mile)的问题（路由器，移动数据网络等）也会引起丢包抖动
实时语音的问题很难去定位 语音卡顿，到底是什么原因？ 问题多源性：你首先想到的肯定是网络，网络会卡顿。 其实还有别的原因会引起卡顿，比如设备CPU负荷很高时，录放音调度有问题，也会导致声音的卡顿。更隐性的问题，比如回声消除，
2.设备 （声学设计，计算能力）：听感体验很大程度受到录放音设备的制约,扬声器之间的耦合很大，或者扬声器的非线性很大，导致你的算法不能很好贯通在上面，导致听感上有一些卡顿、毛刺的问题。
3.物理环境 (密闭环境，噪声, 啸叫等)比如我在一个很吵的环境和你打电话，或者我在很小的房间跟你打电话感觉是不一样的；还有远场拾音，比如做电视应用，必须要在2米以外收音，这个时候麦克风的拾音效果决定了音频听到的体验
听音
建议对通话进行录音，这样可以在测试后重听和标注，更好的分析问题。如果测试的引擎不带录音的话，可以在外放的而环境通过外部设备来录制。
一般我们先在较好的网络状态下测试音频的基础质量，然后慢慢增加丢包率来测试一个引擎抗丢包的边界。
音频软件开发中的debug方法和工具
1 log
2 最小系统法
做一个软件系统时刚开始是一个最小系统，即缺了任何一个模块，系统不能用。后来加上一个个功能使系统完备。在写代码时我们可以加上一些标志位使这些后加的功能enable或者disable。这有助于后面出现问题时排查。下图是语音通信的软件框图，最小系统是采集播放编解码网络发送接收等，没有这些不能通话。而前处理的一些模块（AEC/ANS/AGC等）则不是最小系统里面的，它们是后来一步步加上去的。假设系统出问题了，我们先disable前处理的诸多模块，形成最小系统，看有没有问题，有说明问题在最小系统里，再继续调查。没有的话先把AEC使能看有没有问题，有说明问题在AEC里，没有说明问题在ANS或者AGC里。如没有问题继续使能ANS看是否有问题，有说明问题在ANS里，没有说明问题在AGC里。经过这几步基本定位问题在哪个模块里，后面再结合其他方法直到找到根本原因。
音频开发时不管是voice还是music好多问题是音频听下来不对，这时就要用音频特有的debug方法了。
3 dump音频数据
Dump音频数据就是把音频数据dump出来用工具（比如CoolEdit, 后面讲工具时会具体讲）播放，或者看波形，戀都很专业，有兴趣可以找相关的文章看看。对codec而言，如果支持PLC功能，如G729，就不需要再在外部加PLC功能了，只需要对codec做相应的配置，让它的PLC功能使能。如果不支持PLC功能，如G711，就需要在外部实现PLC。
PLC对小的丢包率（< 15%）有比较好的效果，大的丢包率效果就不好了，尤其是连续丢包，第一个丢的包补偿效果还不错，越到后面丢的包效果越差。
把Jitter Buffer、FEC、PLC结合起来就可以得到如下的接收侧针对网络环境因素的提高音质方案：
从网络收到的RTP包如是原始包不仅要PUT进JB，还要PUT进FEC。如是冗余包则只PUT进FEC，在FEC中如果一组包中原始包的个数加上冗余包的个数达到指定值就开始做FEC解码得到丢失的原始包，并把那些丢失的原始包PUT进JB。在需要的时候把语音帧从JB中GET出解码并有可能做PLC。
4，重传
重传也主要针对丢包这种因素，把丢掉的包再重新传给对方，一般都是采用按需重传的方法。我在用重传的方法时是这样做的：接收方把收到的包排好序后放在buffer里，如果收到RTP包头中的sequence number能被5整除（即模5），就统计一下这个包前面未被播放的包有哪些没收到（即buffer里相应位置为空）， 采用比特位的方式记录下来（当前能被5整除的包的前一个包用比特位0表示，丢包置1，不丢包置0，比特位共16位（short型），所以做多可以看到前16个包是否有丢包），然后组成一个控制包（控制包的payload有两方面信息：当前能被5整除的包的sequence number（short型）以及上面组成的16位的比特位）发给对方，让对方重发这些包。接收方收到这个控制包后就能解析出哪些包丢了，然后重传这些包。在控制包的payload里面也可以把每个丢了的包的sequence number发给对方，这里用比特位主要是减小payload大小，省流量。
在实际使用中重传起的效果不大，主要是因为经常重传包来的太迟，已经错过了播放窗口而只能主动丢弃了。它是这些方法中效果最差的一个。
靠“喂喂喂”来测试实时语音质量靠谱吗？https://blog.csdn.net/agora_cloud/article/details/53007099
你还在靠“喂喂喂”来测语音通话质量吗，看完这篇文章你就能掌握正确姿势。 https://blog.csdn.net/agora_cloud/article/details/51851392
声音“三要素”---响度(loudness)，音高(pitch)，音色(timbre)
https://blog.csdn.net/junllee/article/details/7217435
关于音质评价
https://blog.csdn.net/junllee/article/details/6070881
频率与音色的听音训练 及 训练音乐听觉
https://blog.csdn.net/weixin_43153548/article/details/82731907
语音通信中提高音质的方法
https://blog.csdn.net/david_tym/article/details/80698478
音频软件开发中的debug方法和工具
https://www.cnblogs.com/talkaudiodev/p/7400252.html | 
转播
