音频同步问题（百思不得其解）

[chzuping]

一个服务端和一个客户端，服务端将音频音频数据发送到客户端，客户端收到音频数据后实时播放，现在存在以下问题（在不同的机器上测试过）：

服务端的采样频率是8000，客户以8000的采样频率播放，但是客户端播放不是快了就是慢了，所以要么就出现停顿，要么时间一长客户端的音频缓冲区就会溢出。

问题分析结果：
1.经过测试，服务端发送过来确实是精确的以8000为采样频率，每秒收到16000个字节（每个采样点两个字节）。

2.通过客户端动态调整采样频率可以实现同步，整体思想是当客户端播放速度慢了，就调高采样频率；当客户端速度慢了，就调低采样频率，频率变化范围是（7900~8100）。但是当声音比较丰富的时候，会出现变调。

3.通过动态加减帧来实现同步，整体思想是当客户端播放速度慢了，就往音频缓冲中插入人为构造的音频数据；当客户端速度慢了，就删掉音频缓冲区一些数据。此方法因为难度较大，同时需要在缓冲区中积累一定量的数据才能进行调整，影响实时性，所以目前未具体实现。



本人在网上搜索的很长时间也没有什么收获，以至于百思不得其解，在此请教一下大家，希望各位不腻赐教，先谢谢了：

1. 声卡的频率在不同的机器上会不会有误差，为什么同样的采样频率一段声音，在不同的机器上播放时间会有偏差呢。

2. 如果声卡确实会有误差，那有没有其他的更好的行之有效的解决办法的。

[搬了20多年的砖]

G729编码传送,播放的话,实时的东东收到就播了,还缓存什么.

[icansaymyabc]

采样频率和播放频率决不能变，不得调整，必须一致。

你的问题可能出现在网络延迟上。未压缩的音频数据是非常巨大的，在网络上传输可能导致大的延迟。
当数据的传输速度小于播放速度时，你会觉得播放频率变慢。如果稍后传输速度稍快于播放速度，播放器的同步机制会快速将收到的数据划过以弥补先前延迟的时间。当传输速度远大于播放速度时导致缓冲区溢出。

客户端动态调整采样频率的做法是绝对错误的，除非客户端能预测网络状况。

网络延迟是你无法干涉的，没有任何技术能保证任何数据能稳定地在网络上传递。

因此你的问题的正确解决方法是将音频数据压缩后传递，压缩后的音频会占有很少的网络带宽，而且当前主流的mp3、rm等格式自带同步信息，不会因为网络延迟改变声音的播放频率。

如果你不能压缩你的音频，必须传递原始音频采样的话，你就得改变播放策略。
1、服务器不能持续传送数据。必须由客户端请求才能发送制定大小的数据。
2、客户端必须缓冲收到的音频数据并检测缓冲区的状况。例如，缓冲区的剩余数据必须大于5秒才开始播放，当剩余数据小于1秒就停止播放。

只有做到这两点，才能解决播放出的音频变调的和接收缓冲区溢出的问题。
至于网络延至导致的播放停顿，那是神仙也解决不了的问题（或者你把服务器和客户端之间铺设成千兆光纤网络可以改善）

[liuwei2500]

我觉得客户端在收到数据之后采用立即播放不太好，你如果听过收音机的话，你会很清晰的感触到，电台发出的脉冲信号和你接受到的信号存在将近5秒的时间差。
你说的这个问题我是一个外行人
我觉得你可以客户端在刚收到服务器发送的数据后，先将数据保存。保存两组到三组数据后再开始播放，相当于起到一个延迟的效果。这样以来以一种固定的速度读取是完全没有问题的。

[AlanBruce]

看看。。。

[wryse]

“服务端的采样频率是8000，客户以8000的采样频率播放，但是客户端播放不是快了就是慢了，所以要么就出现停顿，要么时间一长客户端的音频缓冲区就会溢出。”

原始数据应该没有问题，从你的描述来看我感觉应该还是网络传输的问题。停顿是因为网络延时没有数据过来了，音频缓冲区溢出是因为数据来得太快播放跟不上。
解决方法的话，既然你已经有音频缓冲了，那么就是解决网络数据传输的问题了。你可以参考一下流媒体RTSP协议的思路，大致思想是用报文通知服务器快点发还是慢点发，或者干脆利用本地磁盘缓存。网速慢的话考虑先缓冲一段数据再开始播放，就像现在大多数网络视频播放网站做的那样。还有，压缩数据的话，能做尽量还是做吧。
如果真要网络本身卡的厉害的话那就跟icansaymyabc说的一样，仙都救不了了……

[nwao7890]

学习，