原帖由 farrel 于 2012-11-11 16:28 发表 http://bbs.headphoneclub.com/images/common/back.gif
又不是种猪，炫耀一下自己的某项功能突出。。你的耳朵慢慢炫耀吧。。
真有意思，跟一个免费软件过不去，我不是码农，我是玩发烧听音乐的，所以用耳朵收货，你自己甭管是木耳还是聋子爱用用不用滚就是了
你要讲技术建议你跟Jplay作者去说去，人家卖$99，买的人多得是，照你说这些人全是纱布了
另外，好像在这里我只看到你在炫耀，看来你自己承认自己是你说的那个东西了...
[ 本帖最后由 gravity17 于 2012-11-11 16:33 编辑 ]
原帖由 farrel 于 2012-11-11 16:26 发表 http://bbs.headphoneclub.com/images/common/back.gif
好了，总算有一个讲到点技术的了。
DPC latency能看到系统时钟精度？
官方页面：http://www.thesycon.de/deu/latency_check.shtml
来你给我找出来，哪里有精度？
1000us到500us，你非要去用极听去优化啊 ...
本坛的人没兴趣关心技术，你说了也没用
farrel 的回复速度与语法，与隔壁某人很相像，但愿我猜错了:)
原帖由 farrel 于 2012-11-11 16:26 发表 http://bbs.headphoneclub.com/images/common/back.gif
好了，总算有一个讲到点技术的了。
DPC latency能看到系统时钟精度？
官方页面：http://www.thesycon.de/deu/latency_check.shtml
来你给我找出来，哪里有精度？
1000us到500us，你非要去用极听去优化啊 ... Test Interval是根据什么设定的？我不知道DPC latency具体是根据什么设定的，但如果只是他软件内随便写死的1ms的话，没理由极听可以改变这个数。
那么有理由认为他是根据系统的周期走的。
然后……我倒是很想知道系统哪里可以改这个数╮(╯▽╰)╭我觉得500还是太高，想再降降
还有顺便请教一下RTlinux哪里能搞到，据说这东西能到100us
原帖由 amex 于 2012-11-11 16:35 发表 http://bbs.headphoneclub.com/images/common/back.gif
Test Interval是根据什么设定的？我不知道DPC latency具体是根据什么设定的，但如果只是他软件内随便写死的1ms的话，没理由极听可以改变这个数。
那么有理由认为他是根据系统的周期走的。
然后……我倒是很想知 ...
我不是搞软件的，搞的是硬件
但是据我了解软件是无法进行us级别的控制。
但是软件可以做时间读取的操作，这个时间可以精确到毫秒甚至精度更高。
这个软件可能才用的方法是连续进行软件中断请求，然后看看系统在多长时间内能处理完
然后计算一个平均处理的时间间隔。
既然t大能够在很短时间内号称对很多播放器软件进行了优化
并且在没有这些软件源代码的情况下进行优化，
我觉得他不可能修改软件本身的东西，应该是给软件加了一个壳
启动播放器的同学对系统进行某些设置，降低latency
如果从技术角度来讲，其实这个latency和声音一点关系都没有。
如果latency过大直接就爆音，声音断断续续。只要声音连续就没有任何jitter的问题。
软件完全没有机会和能力控制时钟运行的快慢。
我的优化不神奇，懂PE结构和COFF加载过程的谁都能做，而且也确确实实是优化了。
为什么会有效果？因为microsoft linker本身为了兼容性和安全考虑，并没有将性能提到最佳。
上图也能看出来，我加快的是io处理，运算能力并没有变化。而音频、视频任务，对io处理能力更敏感，所以效果更明显些。
我自己的fireworks也优化了，加载速度明显提高，但处理能力并没有变化。
原帖由 thinkspace 于 2012-11-11 16:55 发表 http://bbs.headphoneclub.com/images/common/back.gif
上图也能看出来，我加快的是io处理，运算能力并没有变化。而音频、视频任务，对io处理能力更敏感，所以效果更明显些。
我自己的fireworks也优化了，加载速度明显提高，但处理能力并没有变化。
你既然懂技术，那你说说io对声音为什么会有影响？
io处理快慢到底和声音是什么关系？
原帖由 gaomx 于 2012-11-11 16:41 发表 http://bbs.headphoneclub.com/images/common/back.gif
我不是搞软件的，搞的是硬件
但是据我了解软件是无法进行us级别的控制。
但是软件可以做时间读取的操作，这个时间可以精确到毫秒甚至精度更高。
这个软件可能才用的方法是连续进行软件中断请求，然后看看系统在 ...
windows是按3个cpu时钟周期来处理irq的，windows不是软件？
好吧，说windows极端了点，wdm驱动是100ns处理精度，wdm驱动不是软件？
好吧，说wdm还是有点抬杠，就普通应用程序，只要调用timeBeginPeriod，就可以将时钟精度调高到1ms，但只要你去研究timeBeginPeriod的实现方式，做到0.9到0.5没有技术难度。
原帖由 gaomx 于 2012-11-11 17:02 发表 http://bbs.headphoneclub.com/images/common/back.gif
你既然懂技术，那你说说io对声音为什么会有影响？
io处理快慢到底和声音是什么关系？
因为windows所有的io都是异步的，而win32编程模型是同步的，每次io操作都需要内核进行同步，而内核同步是需要时间的，这样也就降低了系统的实时性。
能理解上面这段话么？
原帖由 thinkspace 于 2012-11-11 17:06 发表 http://bbs.headphoneclub.com/images/common/back.gif
windows是按3个cpu时钟周期来处理irq的，windows不是软件？
好吧，说windows极端了点，wdm驱动是100ns处理精度，wdm驱动不是软件？
好吧，说wdm还是有点抬杠，就普通应用程序，只要调用timeBeginPeriod，就可以将 ...
我知道的是硬件的工作过程，不知道你说的这些如何转换成硬件操作。
驱动是硬件和软件之间的桥梁
硬件能做的事情就是按照主板上晶振的时钟频率，当然通过一些频率变换
将软件准备的放在内存中的数据源源不断的取出来，然后送给声卡处理
你说的那些东西还没有到达最后的发送阶段，还差得远。还是软件层面的处理
我一直有一个疑问就是硬件发送的速度，如果和软件定时出现矛盾如何处理
比如硬件处理速度稍稍快一点，数据就断流了，但是软件又是一套定时系统
和硬件发送的时钟是两套系统。
我搞不清楚window的工作方式，但是我觉得软件采用了自己的一套定时系统
如果和硬件时钟出现偏差，就会通过软件插值的方法调整数据的发送情况。
举一个例子比如播放一段音乐，按照软件的和文件内部的标示播放需要100s
但是硬件快了一点，用了99s就发送完了，所以软件就要想办法把原来的文件
通过插值让播放时间变长一点点。
不知道我的想法对不对，哪里能找到详细的音频处理的介绍？
软件没有机会和能力去控制硬件的工作频率和时钟精度。
很丰富的帖子，保存跟踪实时报道！同时感谢TS制作的播放器。
原帖由 gaomx 于 2012-11-11 17:19 发表 http://bbs.headphoneclub.com/images/common/back.gif
我知道的是硬件的工作过程，不知道你说的这些如何转换成硬件操作。
驱动是硬件和软件之间的桥梁
硬件能做的事情就是按照主板上晶振的时钟频率，当然通过一些频率变换
将软件准备的放在内存中的数据源源不断的取 ...
必须说，这个问题是个真正有技术含量的问题，这也是我最开始不了解音频技术时候的困惑。
要回答这个问题，得对SPDIF或AES有所了解，USB、IEEE1394上的音频流技术，都是从AES上派生出来的。
AES数字音频流从原理上说，就是一个RS422串行数据应用，波特率是12M（还是18M 24M不记得了，总之是个固定频率），无硬件纠错，每192个字节为一个数据桢。
AES数据有效位为16位，24位音频通过扩展桢传输，在16位时扩展桢为0，接收端并没有判别扩展桢是否有效的能力，所以它只能以固定的方式接收数据并进行处理。
这是为什么大多数SPDIF解码器可以显示采样率而无法显示采样位深的原因。
SPDIF不存在握手也不存在独立的时钟信号，它的时钟等于数据传输速度乘以2，在每个AES数据桢头，会有三个连续高电平（1）后接一个低电平（0）的校准信号，接收端通过两次接收校准信号来确定时钟。
因此SPDIF的误码率高度依赖数据发送的稳定度，而软件手段能做的，就是尽可能减少干扰，使数据发送到硬件的过程尽量迅速和稳定。
那也需要问，SPDIF接收端不是已经具备时钟重建和数据缓存了吗？不是可以屏蔽这种问题吗？
那就得回过来，SPDIF接收器的问题，时钟重建，这方面我不是太懂硬件原理，我只知道SPDIF数据误差越大，时钟重建的效果也越差
至于SPDIF的接收缓存，那只是桢缓存，不会像数据缓存那么离谱，缓存数据也不会进行处理，错误的数据还是错误的，纠错是要付出代价的。
错误的数据越少，纠错的代价越小，尽量保证数据正确，这就是软件在源头所干的事情。
