- 第 2 页 -
很早前在 saw 論壇也有人問過類似問題
noticed today that for the fastest buffer in the CW options menu it lists 3ms as the latency. Cubase SX2 confirms this as it reports 2.925 input and 2.925 output for latency. Yet in SAW it lists the buffer size as 64. Now if the CW latency is really 3ms then isnt that equivalent to a 128 buffer not 64?
This might explain why SAW seems to add an extra buffer when really what is happening is that when SAW says its using 64 sample buffers whenthe CW hardware is really set for 128.
I did a test where I sent audio into SAW in live mode and also made a copy of this same feed before it hits SAW. Then I sent the direct feed which doesnt go through ASIO to the left input and the output of SAW to the right in wavelab to record. I tried this for for Cubase and SAW to see what the extra latency going in and out of the ASIO drivers were. SAW gave me 326 with 64X1 and SX gave me 262 with lowest buffer setting. These are both aprox 256 which is equal to 128X2, or in other words 128 buffer size happening at both the input and output stages at these apps.
Any other thoughts in this Bob? Again the main control panel for CW lists the latency at 3ms when I have the lowest setting selected. So in this case is it being reported incorrectly in SAW at 64 instead of 128?
By the way for 64X2 SAW gave me 390 which is exactly 64 more than 326 (the 64X1 result). So it still seems like SAW is able to control the ASIO drivers in 64 sample chunks. But I wonder why SAW had a reading of 326 instead of 262 like with SX2 (which seems more on the mark of the expected 256). You'll notice here that 326 is 64 samples longer than 262 as well.
So in this case SAW is starting to already have 64 more samples at the lowest buffer setting than SX2 but from there seems to be able to raise the buffer in 64 size increments which is smaller than what the Creamware options allow you to change.
In the end it looks like the CW stuff isnt imposing any higher latency than expected due to the DSP cards as Robert suggested. And in SX2 it also seems to be reporting the latency correctly. Is there a reason why SAW is adding that initial 64 sample delay on top of the expected 256( or in SX2's case 262, close enough...)?
Jesse
noticed today that for the fastest buffer in the CW options menu it lists 3ms as the latency. Cubase SX2 confirms this as it reports 2.925 input and 2.925 output for latency. Yet in SAW it lists the buffer size as 64. Now if the CW latency is really 3ms then isnt that equivalent to a 128 buffer not 64?
This might explain why SAW seems to add an extra buffer when really what is happening is that when SAW says its using 64 sample buffers whenthe CW hardware is really set for 128.
I did a test where I sent audio into SAW in live mode and also made a copy of this same feed before it hits SAW. Then I sent the direct feed which doesnt go through ASIO to the left input and the output of SAW to the right in wavelab to record. I tried this for for Cubase and SAW to see what the extra latency going in and out of the ASIO drivers were. SAW gave me 326 with 64X1 and SX gave me 262 with lowest buffer setting. These are both aprox 256 which is equal to 128X2, or in other words 128 buffer size happening at both the input and output stages at these apps.
Any other thoughts in this Bob? Again the main control panel for CW lists the latency at 3ms when I have the lowest setting selected. So in this case is it being reported incorrectly in SAW at 64 instead of 128?
By the way for 64X2 SAW gave me 390 which is exactly 64 more than 326 (the 64X1 result). So it still seems like SAW is able to control the ASIO drivers in 64 sample chunks. But I wonder why SAW had a reading of 326 instead of 262 like with SX2 (which seems more on the mark of the expected 256). You'll notice here that 326 is 64 samples longer than 262 as well.
So in this case SAW is starting to already have 64 more samples at the lowest buffer setting than SX2 but from there seems to be able to raise the buffer in 64 size increments which is smaller than what the Creamware options allow you to change.
In the end it looks like the CW stuff isnt imposing any higher latency than expected due to the DSP cards as Robert suggested. And in SX2 it also seems to be reporting the latency correctly. Is there a reason why SAW is adding that initial 64 sample delay on top of the expected 256( or in SX2's case 262, close enough...)?
Jesse
bob 的回復
Jesse, when using Live mode, there is an extra latency imposed in order to allow the delayed input buffers, which are always at least one buffer late (it takes at least one buffer cycle for the input data to be passed on to the app) to be mixed in sync with the MT data.
ASIO apps generally have no separate adjustment for extra buffers to be added to the processing stream... ASIO only uses a 2 buffer switching protocol... one buffer gets filled while the other is playing... but in my opinion, this leaves no room for any performance lags in the Windows system before the data is not processed in time.
SAWStudio's engine is designed a little different and does allow extra buffers to be pre-processed if desired so that any slowdown in the Windows system due to heavy display processing or any other background activity does not cause output glitches due to the fact that a few extra buffers have already been preprocessed and are ready to go.
There are more compications beyond this, but this gets really complex inside the engine.
Try your tests with simple playback and direct input recording... not live mode where console channels are assigned to soundcard inputs. See if things come out more as expected.
You can also compensate for recording latency delay now using the new option in the Driver Model option of the Options menu... but this will not affect actual live input latency.
Jesse, when using Live mode, there is an extra latency imposed in order to allow the delayed input buffers, which are always at least one buffer late (it takes at least one buffer cycle for the input data to be passed on to the app) to be mixed in sync with the MT data.
ASIO apps generally have no separate adjustment for extra buffers to be added to the processing stream... ASIO only uses a 2 buffer switching protocol... one buffer gets filled while the other is playing... but in my opinion, this leaves no room for any performance lags in the Windows system before the data is not processed in time.
SAWStudio's engine is designed a little different and does allow extra buffers to be pre-processed if desired so that any slowdown in the Windows system due to heavy display processing or any other background activity does not cause output glitches due to the fact that a few extra buffers have already been preprocessed and are ready to go.
There are more compications beyond this, but this gets really complex inside the engine.
Try your tests with simple playback and direct input recording... not live mode where console channels are assigned to soundcard inputs. See if things come out more as expected.
You can also compensate for recording latency delay now using the new option in the Driver Model option of the Options menu... but this will not affect actual live input latency.
正常的mix 如果不用太大延遲的插件, 一般都沒有問題, 尤其用 saw 的更加可以肯定, 現在我很多時都在64下, 如果要混合用 dsp類插件就會加至 128或 256 , 已經很久沒有使用 512了, 除了最近一個 33軌的 24/96工程, 足足花了saw的 資源 30%....![]()
(一堆 saw 的 eq , comp , delay、一個 saw reverb, 幾個 stillwell vibe eq+ 一個eventplus limiter , 3 個 uad-1和 1 個 poco 插件)
[ 本帖最后由 himhui 于 08-9-20 18:36 编辑 ]
[ 本帖最后由 himhui 于 08-9-20 18:36 编辑 ]
剛剛試了一個40多軌的工作程(24/48)...把鼓組分別安排到 output 2通道 (輸出為 聲卡1-2), output 4 通遁 (spl vitalizer+dynamaxx 輸出為 聲卡7-8, 聲卡 out 7-8連接聲卡的 in 3-4 作為錄音, 以 聲卡 1-2 作監聽 ) 一堆saw 的eq comp delay, 一個uad-1 dimension d , 2個 vss3 +1個 classverb, 在 128, 256和 512 也沒問題, 64就顯示buffer overun, 本來想找video上來, 但同時攝錄畫面的話, 就算在 512buffer找下來的聲音也卡.....
補充, 沒有用 force realtime priority
[ 本帖最后由 himhui 于 08-9-21 15:14 编辑 ]
補充, 沒有用 force realtime priority
[ 本帖最后由 himhui 于 08-9-21 15:14 编辑 ]