Premium Membership - All Voxengo Plugins at a Fixed One-Time Fee - Click Here For More Info
Forums     Plugins     Pristine Space asio buffer size


<<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 ?


Yannick: So, when using PS at 256 buffer, it would be recommended to set asio buffer to 1024 ?

This is correct.

Yannick: And when using PS with the realtime setting ?

The higher ASIO buffer size you can set the better.  However, it should be noted that PS's 'zero latency' mode does not have a good CPU load spread performance.  If you get glitching it is better to switch to 64 sample latency and set ASIO block to 128, or even try 64 as well.

Yannick: 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)

Crackles happen because PS from time to time (due to its block processing nature) takes more CPU time than what you would expect from 'real-time' process.  That is why for additional 'crackle safety' it is suggested to set audiocard buffer size to a higher value than the latency of PS - it just allows CPU load burst to finish before the start of the next audio frame.

Yannick: Maybe this can change with the new core2duo CPUs ?

I do not think so.  This is not a problem of PS's design, but more a problem of convolution processing itself.  I'm now preparing bits for the next PS version, and I have approached this 'CPU spike' problem once again - I hope CPU load performance can be made a bit better in the next version.


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 ?


I think that using convolution reverb in a live situation is a bit risky business - unless you can devote a whole PC for it (that should work similar to an outboard convolution reverb).

By the way, it is theoretically possible to fully resolve the problem of spiking, but such algorithm will take at least two times more CPU, because we'll have to use a very slow, elementary FFT algorithm, but whose calculations can be spread over time evenly.  Such algorithm will also take more CPU for the given output latency, because in comparison to PS, its real latency will be 2 times higher.  PS's latency is already 2 times higher than what it is possible to have when you are not performing any CPU load spreading.

I think that using convolution reverb in a live situation is a bit risky business

Yes.  But, my setup involves a DSP card mixer which uses the PC for control and VST plugins only.  I do not use PS live often, but for some contemporary music (Dialogue de l'ombre double - Pierre Boulez) I need to.  Because it works better than other solutions (in this piece you need a piano reverb, which involves a PA/piano/mic backstage, with bleed and colored live sound and feedback problems.  In PS you just cut out the bleed = no more coloration and no feedback).  We are talking about 20-60s reverb here !

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.


Do you think offering something like 'stable' convolution processing mode is useful?  It will be as stable as running something like 20 compressors or EQs - CPU load is high, but you don't get spikes.  I can try working on such mode.

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 ?


Spikeless 80% load is a good example I think.

By the way (thoughts about 'spikeless' threshold).  The more 'advanced' processors become - i.e. the more 'advanced' branching prediction, pipeline execution and other 'tweaks' they use, the lower the 'spikeless' threshold becomes, unfortunately.  Such 'advanced' CPU execution methods do not guarantee a steady CPU/memory load and so, you cannot rely on CPU load meter, because it shows an average CPU load while 'advanced' CPU execution methods increase CPU load spread - in some cases they reduce CPU load, but when circumstances change, CPU load may increase: I think it can vary +/- 10%, which is a lot, of course, and so, the 'spikeless' threshold should be decreased to 80-85%.
This topic was last updated 180 days ago, and thus it was archived.  Replying is disabled for this topic.