o*D
2 楼
从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
都没有明显的 delay
据说人的反应最短时间是0.1秒,delay大约0.1秒
人会感觉出来,对话有困难
这就怪了
按说,从美国到中国,哪怕是球面距离都1万多公里
顶1/20光、电流每秒走过的距离
也就是说,哪怕是直接连线两地,没有任何中间结点
至少也有1/20的delay
事实上,现在所有的电话,包括固定电话
都是以数据包的形式在传输话音
这些数据包要经过n道路由
路由本身处理这些包就需要时间
找到合适的路径,才会转播出去
还有数据包的到达时间是不可预测的
因为网络的traffic实在是不可预测
这样,原本按顺序发出的数据包
未必按顺序到达
而重构语音,通常需要这些顺序的包(虽然有些算法也可以
支持在缺失部分包的时候,用imputation解决插值问题)
这就需要等待,即使imputation也需要等待吧?至少要等到确信
哪个包丢了,需要imputation
还有,终端上的coding 和 decoding,都需要时间
所有这些环节加起来,居然没有超过0.1秒?
都没有明显的 delay
据说人的反应最短时间是0.1秒,delay大约0.1秒
人会感觉出来,对话有困难
这就怪了
按说,从美国到中国,哪怕是球面距离都1万多公里
顶1/20光、电流每秒走过的距离
也就是说,哪怕是直接连线两地,没有任何中间结点
至少也有1/20的delay
事实上,现在所有的电话,包括固定电话
都是以数据包的形式在传输话音
这些数据包要经过n道路由
路由本身处理这些包就需要时间
找到合适的路径,才会转播出去
还有数据包的到达时间是不可预测的
因为网络的traffic实在是不可预测
这样,原本按顺序发出的数据包
未必按顺序到达
而重构语音,通常需要这些顺序的包(虽然有些算法也可以
支持在缺失部分包的时候,用imputation解决插值问题)
这就需要等待,即使imputation也需要等待吧?至少要等到确信
哪个包丢了,需要imputation
还有,终端上的coding 和 decoding,都需要时间
所有这些环节加起来,居然没有超过0.1秒?
S*d
3 楼
it is hard to compete with twitter...
a*l
14 楼
其实当年ip电话刚开始的时候的确是延迟非常严重,也就是近几年才随着网络速度的提
升通话效果才好的.网快了,不丢包了,处理就迅速了,也不用什么imputation(我怀疑是
interpolation)了.
【在 o*****D 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
升通话效果才好的.网快了,不丢包了,处理就迅速了,也不用什么imputation(我怀疑是
interpolation)了.
【在 o*****D 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
i*t
16 楼
当然有延迟还不小,可以让对方把你声音放大传回来,延迟立刻显现出来
c*e
18 楼
很明显的delay,如果声音大些从对方话筒再传过来的话能听出,起码大半秒来回。
f*i
19 楼
业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
就算是空气传送,相距30米也有1/10秒的延迟呢。
咋实现<=150ms呢?
小数据包,小/零缓冲收/发,QoS队列优先级。
在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
FTP和HTTP的数据流可以多等一会儿。
语音服务基本上缓冲很小,数据包丢了就丢了,因为每个包都
小,所以损失不大,大家互相猜猜就可以了。
视频就不一样了,缓冲区小了连图像都看不完整,另外丢包的后果
很严重(解压缩差一个包就是一大片难看马赛克),所以用更加可
靠的TCP传送,这时候如果要语音同步,就必然引入同样长度的延
迟,和IP电话对比起来差别明显。
还有,现在的路由器通常不会把同一会话的数据包送到不同的节点,
因此颠倒次序的事情很少发生。
【在 o*****D 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
就算是空气传送,相距30米也有1/10秒的延迟呢。
咋实现<=150ms呢?
小数据包,小/零缓冲收/发,QoS队列优先级。
在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
FTP和HTTP的数据流可以多等一会儿。
语音服务基本上缓冲很小,数据包丢了就丢了,因为每个包都
小,所以损失不大,大家互相猜猜就可以了。
视频就不一样了,缓冲区小了连图像都看不完整,另外丢包的后果
很严重(解压缩差一个包就是一大片难看马赛克),所以用更加可
靠的TCP传送,这时候如果要语音同步,就必然引入同样长度的延
迟,和IP电话对比起来差别明显。
还有,现在的路由器通常不会把同一会话的数据包送到不同的节点,
因此颠倒次序的事情很少发生。
【在 o*****D 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
o*D
20 楼
that makes a lot of sense
【在 f*****i 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
【在 f*****i 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
o*D
21 楼
从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
都没有明显的 delay
据说人的反应最短时间是0.1秒,delay大约0.1秒
人会感觉出来,对话有困难
这就怪了
按说,从美国到中国,哪怕是球面距离都1万多公里
顶1/20光、电流每秒走过的距离
也就是说,哪怕是直接连线两地,没有任何中间结点
至少也有1/20的delay
事实上,现在所有的电话,包括固定电话
都是以数据包的形式在传输话音
这些数据包要经过n道路由
路由本身处理这些包就需要时间
找到合适的路径,才会转播出去
还有数据包的到达时间是不可预测的
因为网络的traffic实在是不可预测
这样,原本按顺序发出的数据包
未必按顺序到达
而重构语音,通常需要这些顺序的包(虽然有些算法也可以
支持在缺失部分包的时候,用imputation解决插值问题)
这就需要等待,即使imputation也需要等待吧?至少要等到确信
哪个包丢了,需要imputation
还有,终端上的coding 和 decoding,都需要时间
所有这些环节加起来,居然没有超过0.1秒?
都没有明显的 delay
据说人的反应最短时间是0.1秒,delay大约0.1秒
人会感觉出来,对话有困难
这就怪了
按说,从美国到中国,哪怕是球面距离都1万多公里
顶1/20光、电流每秒走过的距离
也就是说,哪怕是直接连线两地,没有任何中间结点
至少也有1/20的delay
事实上,现在所有的电话,包括固定电话
都是以数据包的形式在传输话音
这些数据包要经过n道路由
路由本身处理这些包就需要时间
找到合适的路径,才会转播出去
还有数据包的到达时间是不可预测的
因为网络的traffic实在是不可预测
这样,原本按顺序发出的数据包
未必按顺序到达
而重构语音,通常需要这些顺序的包(虽然有些算法也可以
支持在缺失部分包的时候,用imputation解决插值问题)
这就需要等待,即使imputation也需要等待吧?至少要等到确信
哪个包丢了,需要imputation
还有,终端上的coding 和 decoding,都需要时间
所有这些环节加起来,居然没有超过0.1秒?
a*l
30 楼
其实当年ip电话刚开始的时候的确是延迟非常严重,也就是近几年才随着网络速度的提
升通话效果才好的.网快了,不丢包了,处理就迅速了,也不用什么imputation(我怀疑是
interpolation)了.
【在 o*****D 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
升通话效果才好的.网快了,不丢包了,处理就迅速了,也不用什么imputation(我怀疑是
interpolation)了.
【在 o*****D 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
i*t
32 楼
当然有延迟还不小,可以让对方把你声音放大传回来,延迟立刻显现出来
c*e
34 楼
很明显的delay,如果声音大些从对方话筒再传过来的话能听出,起码大半秒来回。
f*i
35 楼
业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
就算是空气传送,相距30米也有1/10秒的延迟呢。
咋实现<=150ms呢?
小数据包,小/零缓冲收/发,QoS队列优先级。
在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
FTP和HTTP的数据流可以多等一会儿。
语音服务基本上缓冲很小,数据包丢了就丢了,因为每个包都
小,所以损失不大,大家互相猜猜就可以了。
视频就不一样了,缓冲区小了连图像都看不完整,另外丢包的后果
很严重(解压缩差一个包就是一大片难看马赛克),所以用更加可
靠的TCP传送,这时候如果要语音同步,就必然引入同样长度的延
迟,和IP电话对比起来差别明显。
还有,现在的路由器通常不会把同一会话的数据包送到不同的节点,
因此颠倒次序的事情很少发生。
【在 o*****D 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
就算是空气传送,相距30米也有1/10秒的延迟呢。
咋实现<=150ms呢?
小数据包,小/零缓冲收/发,QoS队列优先级。
在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
FTP和HTTP的数据流可以多等一会儿。
语音服务基本上缓冲很小,数据包丢了就丢了,因为每个包都
小,所以损失不大,大家互相猜猜就可以了。
视频就不一样了,缓冲区小了连图像都看不完整,另外丢包的后果
很严重(解压缩差一个包就是一大片难看马赛克),所以用更加可
靠的TCP传送,这时候如果要语音同步,就必然引入同样长度的延
迟,和IP电话对比起来差别明显。
还有,现在的路由器通常不会把同一会话的数据包送到不同的节点,
因此颠倒次序的事情很少发生。
【在 o*****D 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 从美国打电话回中国,不管是ip电话,skype,还是手机,固定电话
: 都没有明显的 delay
: 据说人的反应最短时间是0.1秒,delay大约0.1秒
: 人会感觉出来,对话有困难
: 这就怪了
: 按说,从美国到中国,哪怕是球面距离都1万多公里
: 顶1/20光、电流每秒走过的距离
: 也就是说,哪怕是直接连线两地,没有任何中间结点
: 至少也有1/20的delay
: 事实上,现在所有的电话,包括固定电话
o*D
36 楼
that makes a lot of sense
【在 f*****i 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
【在 f*****i 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
s*t
37 楼
LTE 的标准好像就是100ms还是150ms,忘了
【在 f*****i 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
d*l
39 楼
收藏
【在 f*****i 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
【在 f*****i 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 业界的标准,是控制单向传输延迟不超过150毫秒。在150毫秒之内
: 大家不觉得有延迟,因为平时对话的双方都在说话前后给对方留
: 思考的时间,而且打长途电话大家会自然觉得在和远距离的人喊话,
: 就算是空气传送,相距30米也有1/10秒的延迟呢。
: 咋实现<=150ms呢?
: 小数据包,小/零缓冲收/发,QoS队列优先级。
: 在沿途的路尤器通常缓冲区大,吞吐量也大,耽搁的时间不长,
: 但是为了保证语音数据包按时传送,会给不同的数据排不同的队列.
: IP电话的数据包通常是udp偶数端口,优先通过;大的TCP包比如
: FTP和HTTP的数据流可以多等一会儿。
S*n
44 楼
there is a delay,
trying call yourself using different phones
you can feel the delay
trying call yourself using different phones
you can feel the delay
相关阅读
sibeam被收购了Any Handy Open Source Software for C to VHDL/Verilog ?TI 买了National了有位老师要招phd.大牛们看看这个rain sensor啥工作原理啊? (转载)Fresh PHD, 何去何从。问前途,请各位指点。想请人从pudn上下载几个源码电路方面的专利对公司究竟有什么好处关于on-site的几个问题!请问一下什么地方买到放单片光学镜片的小塑料盒没有rebutal的会议被拒申诉有用吗?不想被阿三压榨, 困惑,求建议有谁面试过Marvell的嵌入式方面的职位?EE Master Stony Brook U 和TAMU求比较微软加薪Gatech读Power Electronics美国就业率高吗?收到了ADI的offer,求建议。问几个IC physical design的问题有人参加今年的IEEE PVSC吗?想找个人share旅馆房间。。。现在都有什么公司在招人?