- 第 4 页 -
软件延迟确实存在着一些影响 我戴封闭耳机录演唱时
使用声卡监听的话 会走调得很严重
但是如果使用调音台的模拟通路来监听 就没有这个问题
不信你试试 电吉他的话 如果听用封闭的不是很严实的耳机听从声卡返回的声音
和琴弦直接发出来的声音混在一起 直接就有Chorus的效果了
但是用音箱+单块就不会这样
另外 软件效果器还是存在着不方便的问题
录音不等于音乐 有灵感的时候还是希望能有一样打开就能用的乐器
等到你启动好电脑 打开软件效果器 接好吉他和声卡 那点动机早就到九霄云外去了
还有 前面有人提到过话筒的问题 说有再好的硬件 不会调话筒也没有用
但是只有被记录下来的才算是音乐吗？
对于音乐来说 录音只是辅助技术 虽说这是划时代的伟大技术 可以帮我们保留很多伟大的作品
但是也造就了大批的垃圾作品
有了MIDI 键盘演奏者可以不必完整无误地演奏一支乐曲 可以逐段逐小节设置逐音符录入 错了也不要紧 可以后期修补
歌手唱跑了也不要紧 可以修
啥都可以修 。。。。
可以说数字音频技术发展到现在已经开始拖艺术的后腿了
乐器1经过话筒进行声电转换 经过话放 经过AD 经过音轨上的一大堆软件压限和效果器 经过总线上的Limiter 经过DA 再经过扬声器做电声转换 再通过空气以纵波的形式传到耳朵里
乐器2直接发出声音 通过空气以纵波的形式传到耳朵里
你说你愿意听哪一个呢？
之前和一个论坛上的兄弟讨论某软件模拟器里的BASSMAN
兄弟说谁他妈听过真的BASSMAN啥动静啊
我说听听SRV的录音能体会下吧
兄弟说那个早他妈压得不是原型了。。。。
我觉得现在更应该回归真实
直接听听真实的乐器物理上发出的声音吧
多来演奏真实的乐器吧
会让你更加感动
这不是软和硬的问题
这都是寂寞
使用声卡监听的话 会走调得很严重
但是如果使用调音台的模拟通路来监听 就没有这个问题
不信你试试 电吉他的话 如果听用封闭的不是很严实的耳机听从声卡返回的声音
和琴弦直接发出来的声音混在一起 直接就有Chorus的效果了
但是用音箱+单块就不会这样
另外 软件效果器还是存在着不方便的问题
录音不等于音乐 有灵感的时候还是希望能有一样打开就能用的乐器
等到你启动好电脑 打开软件效果器 接好吉他和声卡 那点动机早就到九霄云外去了
还有 前面有人提到过话筒的问题 说有再好的硬件 不会调话筒也没有用
但是只有被记录下来的才算是音乐吗？
对于音乐来说 录音只是辅助技术 虽说这是划时代的伟大技术 可以帮我们保留很多伟大的作品
但是也造就了大批的垃圾作品
有了MIDI 键盘演奏者可以不必完整无误地演奏一支乐曲 可以逐段逐小节设置逐音符录入 错了也不要紧 可以后期修补
歌手唱跑了也不要紧 可以修
啥都可以修 。。。。
可以说数字音频技术发展到现在已经开始拖艺术的后腿了
乐器1经过话筒进行声电转换 经过话放 经过AD 经过音轨上的一大堆软件压限和效果器 经过总线上的Limiter 经过DA 再经过扬声器做电声转换 再通过空气以纵波的形式传到耳朵里
乐器2直接发出声音 通过空气以纵波的形式传到耳朵里
你说你愿意听哪一个呢？
之前和一个论坛上的兄弟讨论某软件模拟器里的BASSMAN
兄弟说谁他妈听过真的BASSMAN啥动静啊
我说听听SRV的录音能体会下吧
兄弟说那个早他妈压得不是原型了。。。。
我觉得现在更应该回归真实
直接听听真实的乐器物理上发出的声音吧
多来演奏真实的乐器吧
会让你更加感动
这不是软和硬的问题
这都是寂寞
看来延迟的问题确实很重要。。想和大家继续讨论下。。。首先，我实验过了。。开心老爹说的是对的。。以前，我也认为。。ASIO 缓冲调到512也决不会有问题的。。缓冲512的情况下，延迟是10MS。。其实，实际情况是，不止。。10MS只是输入解码的延迟。。而实际声卡的延迟，是2倍。。应该是20MS。。大家用过RIG 4就知道了，如果调到512的话，上面有个输入延迟10MS，输出延迟10MS。。总延迟。。20MS。。再有，我也确实感受了一下。。把延迟调到10MS（缓冲区512）和7MS（缓冲区320）对比了下。。手感不一样。。10MS可以说。。我完全可以感觉到延迟。。完全可以感觉到，那声音，根本跟不上我的速度。。然后又调了7MS的和5MS的做了对比，，感觉手感还是有巨大差距的。。至于说5MS以下，我的声卡就达不到了，所以我无从知晓如何了。。但感觉哪怕是5MS的延迟，还是感觉手感怪怪的。。因为上面标是5MS，实际得有10MS了。。相当于离音箱3.5米距离的延迟了。。当然，这一切是要在快速的演奏下才能实验出来的，如果玩SLASH的东西，即使10MS也感觉不出延迟啊。。所以，确实是实践出真知啊。。。开心老爹的观点是完全正确的。。我现在知道了，电吉他玩软件，必须有个低延迟的声卡，把延迟做到2MS还是非常有必要的。。否则手感确实不对头啊。。
为了更广泛的讨论延迟，我复制了黑幕管理员的翻译，方便大家研究：
以下是BOB讲一些有关 asio, wdm, mme, dwave 驱动
-----------------------------------------------------------------------------------------------------------------------
ASIO... I don't like the loosness of it... drivers try to control the app... it should be the other way around, in my opinion.... the driver simply needs to move data to and from ram as efficiently as possible... not take control of everything and dictate buffer formats and sizes etc to the app.
我不喜欢 asio 驱动音图控制主应用软件, 它需要做的应该是以有效率的速度由内存记忆体移动数据, 而不是向主软体控制所有 和 指挥缓冲的格式与大少。
Too many formats... too much splitting and merging of data, in all kinds of possible formats... the app needs to try to handle way too many possibilities... its very complex inside an engine like SAWStudio...
太多不同格式, 太多须分道和紧急的数据, 也有太多不同格式需由 主应用软件去处理不同的可能性, 尤其好像 sawstudio 这样非常复杂的引擎。
ASIO is too easily stepped on by Windows and other threads... there is no room whatsoever for any interruptions in data flow... which will ALWAYS happen at the most inopportune times in Windows... when it does... ASIO spits out repeats of the last buffer... horrible sound...
asio 很容易受 windows 或其他工作影响, 没有足够空间给予中途需处理的数据, 造成错失处理数据之时间, 结果asio就会重复上一个缓冲, 这时怪声便会发出!!
I won't touch true WDM... its probably the worst driver model I've ever fooled with...
我不会碰真正的wdm, 它可能是我见过最不济的驱动!
At least with the MME, I can control sending multiple buffers ahead when I know Windows might interfere with data flow... like when its about to repaint 15 windows onscreen... or when the app is about to minimize...etc..
当 windows 有干扰数据的流程时, mme 驱动至少让我可预先送出多个缓冲, 如windows重划图案, 缩小视窗...等等。
With ASIO... there is only one buffer playing... and one filling... any interruptions whatsoever... and you have a glitch... and a nasty one at that in most cases...
asio 只能进行一个缓冲和 一个补充的, 任何干扰都会构成 "短时脉冲波形干扰" 和 任何可能性的噪音
With DWave... everything is different... DWave does not require any communication between the app and driver during playback or record... no thread interruptions... no context switching between Rings... the driver already knows where to look for the data and pulls it at its own hardware rate without needing to interrupt Windows in any way to ask the app for the next buffer... the app fills the buffers as far in front as it wants... when it wants... without any need to talk to the driver directly during playback or record... the difference is beyond better... at least in my opinion.
dwave 是全然不同, 当播放或录音时, 它不须要应用程式和驱动之间作沟通, 不受其他工作干扰.......驱动早已知道数据在那儿, 并以硬件本身的速度提取, 无须经windows向应用软件要求下一个缓冲.....应用软件在播放和录音亦无须通知驱动,以最快速度填补缓冲...dwave与其他的分别是超越了一般好的程度, 至少我认为。
I'd love to see more soundcards supporting it... but unfortunately, until SAWStudio has sales in the tens of thousands, that most likely wont happen.
我希望看到更多声卡支持 dwave, 可惜sawstudio 的市场占有率只有 1%, 看来实现的机会不太大。 (bob 太坦白, 所以其言可信
)
I wish they were more concerned with the possible performance and quality benefits, but as long as they can sell mass numbers of products with lots of advertising and political connections, things most likely wont change.
我渴望他们(厂商) 真的能够多关心声卡可行的表现和有利于品质的因素。 不过, 只要是能经过大量广告宣传和政治关系从而能卖出更多的产品的话, 这局面似乎难以改变。
Thanks to the former Sonorus and Dirk from the former Soundscape for jumping headfirst into making the idea come alive, so at least we could see it work and give those that said this model couldn't fly a chance to see it in the air.
多谢 前 soundscape 的 sonorus 和 dirk 首先令到我的主要能够实现, 至少能让我们知道这是可行的。
With more interest from other soundcard companies, we could really nail down any remaining loose ends and develop it to be what the standards driver models should have been.
若更多声卡厂商有兴趣, 我们就可真正知道dwave尚欠的东西, 从而发展出一个真正应有的驱动标准出来。
Heh.... you asked. (你们一起去要求吧!!)
Bob L
以下是BOB讲一些有关 asio, wdm, mme, dwave 驱动
-----------------------------------------------------------------------------------------------------------------------
ASIO... I don't like the loosness of it... drivers try to control the app... it should be the other way around, in my opinion.... the driver simply needs to move data to and from ram as efficiently as possible... not take control of everything and dictate buffer formats and sizes etc to the app.
我不喜欢 asio 驱动音图控制主应用软件, 它需要做的应该是以有效率的速度由内存记忆体移动数据, 而不是向主软体控制所有 和 指挥缓冲的格式与大少。
Too many formats... too much splitting and merging of data, in all kinds of possible formats... the app needs to try to handle way too many possibilities... its very complex inside an engine like SAWStudio...
太多不同格式, 太多须分道和紧急的数据, 也有太多不同格式需由 主应用软件去处理不同的可能性, 尤其好像 sawstudio 这样非常复杂的引擎。
ASIO is too easily stepped on by Windows and other threads... there is no room whatsoever for any interruptions in data flow... which will ALWAYS happen at the most inopportune times in Windows... when it does... ASIO spits out repeats of the last buffer... horrible sound...
asio 很容易受 windows 或其他工作影响, 没有足够空间给予中途需处理的数据, 造成错失处理数据之时间, 结果asio就会重复上一个缓冲, 这时怪声便会发出!!
I won't touch true WDM... its probably the worst driver model I've ever fooled with...
我不会碰真正的wdm, 它可能是我见过最不济的驱动!
At least with the MME, I can control sending multiple buffers ahead when I know Windows might interfere with data flow... like when its about to repaint 15 windows onscreen... or when the app is about to minimize...etc..
当 windows 有干扰数据的流程时, mme 驱动至少让我可预先送出多个缓冲, 如windows重划图案, 缩小视窗...等等。
With ASIO... there is only one buffer playing... and one filling... any interruptions whatsoever... and you have a glitch... and a nasty one at that in most cases...
asio 只能进行一个缓冲和 一个补充的, 任何干扰都会构成 "短时脉冲波形干扰" 和 任何可能性的噪音
With DWave... everything is different... DWave does not require any communication between the app and driver during playback or record... no thread interruptions... no context switching between Rings... the driver already knows where to look for the data and pulls it at its own hardware rate without needing to interrupt Windows in any way to ask the app for the next buffer... the app fills the buffers as far in front as it wants... when it wants... without any need to talk to the driver directly during playback or record... the difference is beyond better... at least in my opinion.
dwave 是全然不同, 当播放或录音时, 它不须要应用程式和驱动之间作沟通, 不受其他工作干扰.......驱动早已知道数据在那儿, 并以硬件本身的速度提取, 无须经windows向应用软件要求下一个缓冲.....应用软件在播放和录音亦无须通知驱动,以最快速度填补缓冲...dwave与其他的分别是超越了一般好的程度, 至少我认为。
I'd love to see more soundcards supporting it... but unfortunately, until SAWStudio has sales in the tens of thousands, that most likely wont happen.
我希望看到更多声卡支持 dwave, 可惜sawstudio 的市场占有率只有 1%, 看来实现的机会不太大。 (bob 太坦白, 所以其言可信
) I wish they were more concerned with the possible performance and quality benefits, but as long as they can sell mass numbers of products with lots of advertising and political connections, things most likely wont change.
我渴望他们(厂商) 真的能够多关心声卡可行的表现和有利于品质的因素。 不过, 只要是能经过大量广告宣传和政治关系从而能卖出更多的产品的话, 这局面似乎难以改变。
Thanks to the former Sonorus and Dirk from the former Soundscape for jumping headfirst into making the idea come alive, so at least we could see it work and give those that said this model couldn't fly a chance to see it in the air.
多谢 前 soundscape 的 sonorus 和 dirk 首先令到我的主要能够实现, 至少能让我们知道这是可行的。
With more interest from other soundcard companies, we could really nail down any remaining loose ends and develop it to be what the standards driver models should have been.
若更多声卡厂商有兴趣, 我们就可真正知道dwave尚欠的东西, 从而发展出一个真正应有的驱动标准出来。
Heh.... you asked. (你们一起去要求吧!!)
Bob L
这里还有用32采样下的9632声卡，0.7延迟，标称总延迟估计可以达到2sm以内了，
http://www.audiobar.net/viewthread.php?tid=179440&extra=page%3D2%26amp%3Bfilter%3Ddigest
http://www.audiobar.net/viewthread.php?tid=179440&extra=page%3D2%26amp%3Bfilter%3Ddigest
看来软件本身也是有延迟，厂商往往会不提这些东西（GR4比较厚道），saw汇编核心估计是目前最低延迟的daw了。摘录了一段扩音板块黄老师的文章:
AES50数字协议是MIDAS音质获胜的法宝，我们知道所有数字处理都需要时间运行，至少是几次取样时间,，但无一例外都需要时间，ADCs（模-数转换）和DACs （数-模转换）需要更长的延时（一般是几毫秒），所以如果使用模拟插入点的话，该通道就会有比其他更长的延时，以往的数字台由于缺乏对数字信号延时管理的重视，在数字转换中存在着不同的延时而导致在混合中产生梳状滤波器效应，致使输出的信号产生相位失真，是早期数字调音台最被人抗拒的理由，而如今XL8把这个问题完全解决了，AES50形式完全不同于以以太网为基础的系统，它是一个时分多路（TDM）系统，仅利用了以太网的物理分布（电子硬件，连接头，等等），通过TDM允许将单独的取样数据实时传输，不需要数据打包，减少响应时间，在XL8系统上，一个单独的AES50连接只有70μs延时（注:1000μs=1mS）。
AES50数字协议是MIDAS音质获胜的法宝，我们知道所有数字处理都需要时间运行，至少是几次取样时间,，但无一例外都需要时间，ADCs（模-数转换）和DACs （数-模转换）需要更长的延时（一般是几毫秒），所以如果使用模拟插入点的话，该通道就会有比其他更长的延时，以往的数字台由于缺乏对数字信号延时管理的重视，在数字转换中存在着不同的延时而导致在混合中产生梳状滤波器效应，致使输出的信号产生相位失真，是早期数字调音台最被人抗拒的理由，而如今XL8把这个问题完全解决了，AES50形式完全不同于以以太网为基础的系统，它是一个时分多路（TDM）系统，仅利用了以太网的物理分布（电子硬件，连接头，等等），通过TDM允许将单独的取样数据实时传输，不需要数据打包，减少响应时间，在XL8系统上，一个单独的AES50连接只有70μs延时（注:1000μs=1mS）。