1 视频采集，采集的时间就是摄像头捕捉这一帧画面并以YUV或者某些格式拿到，的时间；拿到的画面是时刻性质的。
2音频，拿到的的声音是真实的时间段的东西；是需要先耗时间采集，再积攒，再取得，是一个非时刻性质的东西；
EX：
假设你采集buffer（从麦克风采集PCM后装入这个buffer）8192字节，你要采集满之后，去做编码，编码一帧 G711（8K SP rate）使用640字节；编码一帧MP3（16K SP rate）使用9000字节（这是一个假设的编码一帧所用PCM长度）；假设音频参数，单声道，16位深；（这里不谈比特率，比特率反映了音频的压缩比例，各个公司自己开发的东西也不一样）；你采集-编码-网络传送-对方解码-播放。
我们来看看拿到第一针的耗时？（其实这个耗时并不是真正意义上的耗时，只是拿到这么多数据，所需要的真实时间段）
（假设我们并没有什么重采样，采集的采样率就是我们设置的采样率；）
（1）711, 8K采样率，每毫秒16字节，8192字节就要采集 512毫秒，编码耗时0~1毫秒，那我们拿到第一帧音频的时间就是设备启动以后的第513毫秒左右；你开始听到第一个音量也就在半秒以后，如果网络传递延时比较长，那你听到第一帧的时间会更长；如果播放启动或者播放端还有若干播放缓冲，启动不具备实时性的话，那听到第一帧的时间还会更长； long~~~long~~~long.....
但是由于编码一帧所用字节数640 比较小，8192可以连续消耗很多次，所以你（在采集端）拿到第二帧音频的时间就会 比较短，可能1毫秒；总的来说你拿到本次采集后的编码的所有711数据，会在512+13毫秒左右（编码12.8次 ，假设每次编码一帧用1毫秒）；
从宏观上看数据8192字节和500多毫秒也算是对应关系，你拿到这些数据耗时13毫秒 ，前边的512毫秒是数据产生所需要的时间；但是从微观角度来看，你拿到第一帧音频本来应该是第40毫秒（640字节，8K 采样率，需要40毫秒），可是由于你需要把buffer采集满，再去编码，导致你真正拿到第一帧时候是第513毫秒，整整延后了473毫秒。当然除了第一帧之外，后边的帧就紧随而来几乎不耗时了。。。
（2）16K MP3音频编码一帧需要9000字节；
（其实声音并没有像图片一样严格的帧率，也就没有严格的帧的界定，你的编码SDK可以 使用10毫秒的PCM数据编码一帧，也可以使用20毫秒的PCM编码出来的数据作为一帧，各个公司有自己的算法界定；假设XX公司，它的算法工作人员，开发一个711编码库，它每次处理的帧长支持PCM数据640字节，编码出来128个字节 的711类型音频，那我们可以简单地说它的编码输入帧长是640字节，编码输出帧长是128字节，也可以称呼它为40毫秒帧长。其实本质上都是16进制，二进制，的字节，音频也看不出图片来反正）
我们接着看这个MP3，由于编码一个帧（我们假设他需要9000字节，只是为了举例子，真实场景其实可能几百到几千不等的字节数）需要9000字节，那一次采集的buffer就不够编码一帧，就要等第二次采集，也就是你要等 8192*2这么多自己被采集到之后才能使用里边的前9000个字节，可想而知，也是512毫秒(8192*2/32 =512, 16K采样率，每毫秒采集32字节PCM)，不过这种编码帧长，你每拿一帧编码后的MP3几乎都需要两个采集buffer的时间，当然，一帧数据本身所代表的时间段也比较长。
综上：我们在做采集的时候除了优化启动时间，也要考虑采集buffer的大小，是否采集满在继续后边的操作？采集多少编码一次等逻辑，以及编码一帧设计的消耗PCM的长度等等？
当然 通话耗时有很多地方，网络延时？抖动？ 播放启动的时机？启动播放耗时？ 启动采集耗时？播放是否有缓冲？送播放的数据是否及时播放？编解码耗时（一般可以忽略），一些音频音质优化算法是否实时输出数据内容，是否存在数据内容延后，导致听觉上有延迟？等等很多需要考虑的。
原创禁转，理解有误的地方望指出