播放器硬件加速延迟和硬件损坏有没有关系

[转载]谈谈低延迟对音质的负面影响,顺便谈谈WASAPI
原来与系统定时器精度有关,你这边的理论上升到物理层了,牛!很多人说Foobar会有音染,我觉得就是这个引起的误导。读取还要考虑硬盘碎片化的问题,现在有比WASAPI&、KS、ASIO更牛的插件了,直接加载到RAM播放。之前解决爆音问题就是通过注册表设置,解除一些程序因调用MMCSS造成爆音问题,因为这个服务还有优先级的问题。你这程序再加于开发可以解决很多声卡爆音问题,有空我弄下,呵呵可以公布下源码吧?!谢谢!
咣輝のま裔
转载请注明作者信息,谢谢。
常常看到某些人给别人推荐,或者的时候,总喜欢扯上一句:拥有更低的延迟,从而改善音质。
事实到底是不是这样的呢?让我们来看看作者的看法。
作者这一两句话完全概括了重点,但是并不是所有人都能真正理解其中的道理。
低延迟的唯一好处仅在于录音播音的实时处理,比如将一个人说的话通过扩音器实时的广播,将播放的背景音乐与录制的人声进行实时混音处理等等对时间要求很高的操作。事实上低延迟是为了达到实时处理而不得不做的一种妥协。
缓存欠载是指由于某种原因导致系统传输停顿使缓存不能及时补充有效数据,同时缓存中的数据又已被播放(录制)完,造成缓存中数据为空的现象。
实际上&=&/&+&&而多数情况下偏移量大致为,于是多数情况下&=&/&采样点个数反映了缓冲大小,缓冲大小决定了当前写入位置与播放位置的距离。
播放速度是固定的,如果缓冲大小为,那么就必需时刻保持写入速度等于播放速度,这势必会造成系统频繁调用的高负载。当我们加入了缓冲机制,系统对于写入速度的要求就从瞬时速度降低为平均速度的水平。。
(在播放的时候偏移量可以为负数,这样就实现了延迟,让写入与播放同时进行,由于写入速度快于播放速度,而且播放的内容是可以预知的,这样就能够在预存了足够的采样点后,再保持速度同步。事实上不管是的,还是,设置的都是缓冲大小。)
根据处理方式的不同,缓存欠载会有两种后果:禁音,短时间的禁音在人耳听来就是爆音的效果。重复播放缓冲区,直到有新数据为止,这种处理方式在人耳听来就是一段很短的声音无限重播。
事实上,写入声卡缓冲的速度远快于播放的速度。为了不让线程在写完一个缓冲大小的数据后空载,增加不必要的消耗,有违节能环保的精神。于是每次在写入操作完成后进入睡眠状态(调用或者函数)。
菜鸟级程序员每次都让播放与写入同时开始,写完一个缓冲大小的数据后,便睡眠一个延迟的时间,等待播放完毕。然后又开始播放和写入,不停的重复下去。
这中做法并没有发挥出缓冲的所有优势,只能保证一个缓存大小中的声音是没有差别的。但是。睡眠并不能保证在精确的时刻被唤醒。。一段的声音在的延迟下,将有处交汇处,在的延迟下有处交汇处,在的延迟下有次的交汇处。将延迟从降低为,对声音的影响加剧了倍还不止,而系统频繁调用的次数也增加了倍不止。
以下测试都在没有干扰的情况下进行:
延迟的情况:
平均时间漂移(正负不抵消)体现了两个缓冲交汇处对音质的影响,累计时间漂移(正负不抵消)表示了这种处理方式下对于音质的总体影响,可以看到的声音就有出现了问题。实际上,如果是日常的使用中,最大时间漂移可以轻易突破。
延迟下的对比:
这种做法完全发挥出了缓冲的价值。
那么问题到这里就已经顺利解决了么?
我们知道不管也好还是,其。系统默认情况下是,以及一些调用的程序都会将定时器精度设置为。然而这个值并不是你想设为多少就能设为多少的,这个值只能等于系统中所有程序设置的最小值,而且最高精度只能为,这个值设的太小还会增加系统线程切换的消耗。
那么如果音频的延迟为,在的时间精度下,会如何表现呢:
结果就是每次都睡眠。最终时间严重增长了。为了解决这个问题:
可以看到,在的精度前提下,等待时间不断的在和间变化,实际上延迟的表现还不如,其对于突发高负载的承受力只有的水平。在延迟足够大的情况下,这种方式足以解决简单带来的问题。
遗憾的是,系统定时器分辨率的精度最高只能是,这就给不是整数毫秒的延迟带来了问题。
拿来说,实际上的延迟时间是采样点个,这多余的对于造成问题:
累计时间漂移(正负抵消)已经超过了延迟的倍。。为了解决这个问题:
现在我们不再睡眠一个延迟值了,现在:
&=&n*&-&&-&
这样便解决了零头时间带来的问题。
可以看到平均时间周期已经和延迟基本接近了,累计时间漂移(正负抵消)也得到了很好的控制,但是最大时间漂移超过了,这不是偶然,实际上楼主测试了次,其中次都超过了,次为。
在系统时间精度为的前提下,想要在这种方式下良好工作,延迟至少要。Push-Mode便是这么做的。这也是其缓冲长度必需大于的原因。虽说的缓冲长度与声卡的缓冲大小不是同一个事物,但两者前后承接,工作原理上极其相似。
(其实系统计数器的分辨率可以达到纳秒的级别,但是用在播放器上完全是杀鸡用牛刀。纳秒级别的计数器在大型游戏上常常用到)
我们知道在当前系统时间精度下,为了保证音质不受损,延迟不可能降得太低。为了降低延迟,我们迫切的需要一种不需要高负载轮询,又能高度准确的时间。WASAPI
Event-mode&KSASIO
声卡在每次播放完一个缓冲区后便发送事件通知程序,应用程序便开始将音频数据写入缓冲区。详细图解,请回头看上面的:配合双缓冲,循环播放,动态写缓存。
将你要播放的文件命名为放在同一目录下,然后运行程序就可以播放了。
只支持格式,只支持声卡硬件支持的格式,支持声卡选择。
文件采用全文件缓冲的方式载入,请确保拥有足够的空闲内存(事实上,楼主并不认为全文件缓冲会改善音质。只要声卡缓冲大小(延迟)足够大,全文件缓冲就没有任何意义。楼主这么做完全属于偷懒的做法)。
实际上的兼容性可能在不同的声卡下表现有所不同,楼主基于自己的声卡修正了位音频文件的播放问题。如果在你的机器上播放位音频格式时出现杂音,请留言反馈,楼主可以再发一个未修正的版本。
还能顺便检查下最小延迟以及系统定时器分辨率。
以上两个软件基于,不支持系统。如果遇到问题,可以留言反馈。
如果以上系统无法运行,请安装运行时组件
可以看到累计时间漂移(正负不抵消)减小到了原来的一半,虽然这没什么作用,但是也可以作为一个浮动的观察值。2ms5ms。
你还观察到累计时间漂移(正负抵消)为负数,实际上这是因为声卡的时钟与系统的时钟不同造成的。就好像两杆秤的不一样。如果以声卡的时钟为标准来衡量的话,误差应该很小,只是微妙级别。我前面已经说过了,只要累计时间漂移(正负抵消)的值小于延迟,就不会对声音造成任何影响。
在已运行极品飞车的情况下,对一首分秒的歌曲进行播放测试。
以下测试都做了次以上,不存在突发情况造成的误差。
点评:歌曲播放时间直接增加了秒,最大时间漂移达到,是延迟的倍。。楼主已无法忍受,直接丢掉了耳机,默默地开着车。
点评:累计时间漂移(正负抵消)和最大时间漂移都超过了延迟,虽然不多,但还是对音质产生了一定的影响。50ms
点评:最大时间漂移降低到了,由此可以看出对系统和声卡的压力降低了许多,更加稳定了。明显舒缓了许多,楼主开车头都不晕了,心情也不急躁了,当然这很有可能是心理安慰的作用,哈哈。
点评:与相似的结果,完全在误差范围之内。进一步减轻了系统的负载,对突发事件也拥有了更强的抵抗能力。
多数选项对于你的来说意义不大,不过我还是要推荐下第项(这个工具也能运行)
上面列出的便是下最具兼容性的延迟。强烈推荐,这是这个采样率能够获得的最小整数时间。
如果你希望一个较小的延迟的话,可以设置为:
上面提到的个工具的下载地址:
声卡检测工具播放器延迟测试工具
其实正如作者所说的,只要缓冲足够大,便不会对音质产生多大影响。如果你追求完美的话就把缓冲长度设为的整数倍,比如吧,理由我前面都说过了。
如果你喜欢的话就在设备里选择上,然后在高级里这么设置:
本来的缓冲也应该设为的。很可惜的是,作者写的插件存在很严重的,导致延迟大于左右便会声音播放错乱,严重缩短播放时间,这极有可能是函数超时时间设置过小造成的。所以我不推荐你用,我更倾向于使用延迟的(实际上最大的缓冲时间能达到,作者限制为,估计是在内部做了双缓冲处理)。
线程优先级勾上,模式输入,属于多媒体调度优先级最高的模式了。
全文件缓冲这个除了浪费内存,没有任何好处,按作者默认设置就好:)
终于看完了,如果你觉得本文写的不错,看了之后有所收获,欢迎转载。
以上网友发言只代表其个人观点,不代表新浪网的观点或立场。解决播放机常见故障_百度文库
两大类热门资源免费畅读
续费一年阅读会员,立省24元!
解决播放机常见故障
上传于||文档简介
&&解​决​播​放​机​常​见​故​障
你可能喜欢

我要回帖

更多关于 播放器硬件加速 的文章

 

随机推荐