声音延迟

http://zhubangbing.blog.163.com/blog/static/5260927020098315151876/?suggestedreading&wumii

可视对讲中声音延迟问题的解决  

2009-09-03 13:51:51|  分类： voip|字号 订阅

在前篇文章中http://zhubangbing.blog.163.com/blog/static/5260927020097521658335/
将可视对讲理了个大概，音频延迟没有解决，照金老师的说法，这个样子绝对没法用
后来就找原因
1.首先想到的是不是线程的原因，因为是局域网，因为音频的采集和播放都是硬件完成，想想不会是这方面的原因，就改了线程的优先级，把音频线程的优先级提的很高，又把音频线程作为主进程，折腾了几天，没有什么效果，这段时间的对线程编程倒是了解的更透了点；
2.然后找协议的原因，因为用的是TCP，按照TCP的定义，传输的过程中要经过三次握手，适合传输控制信息，稳定但是实时性差，不适合传输音视频等流量大，实时性强的数据，所以就换成rtp（real time transport protocol::实时传输协议），这个协议的实现是从Mx27中提取出来的，基于udp，实现的相对简单，但是够用；实验的结果比TCP要好，但还是达不到要求
3.后来考虑，视频也是用的TCP协议，视频信息量更大，同样的协议下，视频延迟没有音频大，这个说不过去；基于前两条原因的否定，只能从本地音频的采集上找原因了；确实，在剃掉网络传输的情况下，本地音频一边采一边放都会有延迟，这就确定延迟的大部分原因在本地采集上了，本来用的是数字音频的最低推荐标准：采样率8000，采样位数8
Linux下的音频采集，有很多种格式，我用的是最简单的PCM采集，为什么在本地有延迟呢？一直找不到答案，但在找到答案之前问题还是解决了：
在采样率达到44100，采样位数为16位的时候，音频明显很实时！
后来偶然在华清远见的讲设备驱动书上找到答案，书上的原话是这样的：声卡的采样率是由内核中的驱动程序决定的，而不取决于应用程序从声卡中读取的速度，如果应用程序读取数据的速度过慢，以至于低于声卡的采样频率，那么多余的数据将会被丢弃（即overflow）；这样把这样的数据再按照这样的速度写入声卡时，就会出现声音暂停挥着停顿的现象。所以采样率应该至少等于声卡的采样频率。
但奇怪的是测试程序 record.c中列举的采样率8000，11025，22050,44100,8000也是支持的啊，又试着从wm8987的datasheet中找答案，除了一个本声卡可接16欧或者32欧的headphone可以看懂，其他的全是看不懂的电路，就先放着了
3.还有个问题：到底使用TCP还是UDP？
还是实验结果说话，在声音的延迟解决后，使用TCP的时候声音很实时，但是图像有些卡，使用rtp的时候就不会视频效果基本上没有受到影响。