<<NOTE: It is highly suggested to set your audiocard block size (latency) in accordance with the latency of the plug-in. The most suggested audiocard block size value is four times larger than the value you choose with the "Set Latency..." selector. For example, if you choose "64" then it is suggested to set your audiocard block size to 256 samples. For plug-in latencies above 1024 you may choose the audiocard block size of 4096 samples.>>
So, when using PS at 256 buffer, it would be recommended to set asio buffer to 1024 ?
And when using PS with the realtime setting ?
Could you clarify why this is ? It is obvious that it is fairly difficult to have crackle free playback with low asio/PS buffer settings (even on a D940 with fast ram)
Maybe this can change with the new core2duo CPUs ?
Thanks. That makes everything more clear. The software developers at Soundscape told me a while ago that your PS is rather "spiky", but I already noticed other convolving plugins have the same behaviour.
So if you can change something for the better ...
Anyway, E6700 etc processors do seem to like VERY low latencies much better than even dualcore opterons - I think I'll have to test one of those with PS once. Anyway those core2duo cpus have much more processing speed, so crackling should happen a lot later ?
Also, sometimes (when the client is present) we edit with reverb ON. With 1024+8092 samples delay that is not my idea of fun (feels like editing through remote desktop). On my new PC I can go down to 128+512 samples without issues, even 88K, but then opening the PS window can create havoc.
But the setting 128 and 512 for asio is indeed fine. For very heavy loads I go to double that figure, which is still far better than my previous Athlon 2600XP (9000 samples).
Hence my question about the newest dualcores.
It could be useful. As CPU power now really is going up, I can imagine a few cases where a heavy mode without spikes is preferable. CPU load would be higher, but if we could load the CPU to 90% at lower latencies without getting surprises, that would give us more control.
Anyway, I can have the spikes with the current version on 88K and small buffers, while only loading the CPU around 20-25% (so one core 50%).
I would prefer in this case that the one core would be loaded at 80-100%, but without the spikes. I think this is a good example ?
This topic was last updated 180 days ago, and thus it was archived. Replying is disabled for this topic.