Hi all,if I understand correctly, using the [block~] and [switch~] objects to 
increase the blocksize for a given subpatch, means that the DSP computation for 
that subpatch is delayed until the moment when enough input samples have been 
collected, at which point the entire DSP stack for the subpatch is performed at 
once and the outputs are written to the output buffer.This means that the DSP 
load is not spread over time, rather it is concentrated in that single audio 
driver callback when the buffer for that subpatch happens to be ready to be 
processed.
Now, if what I say makes sense, then this approach has the disadvantage that 
the CPU load is not spread evenly across audio callbacks, eventually causing 
dropouts if whatever computation takes too long in that one callback, forcing 
you to increase the internal buffering of Pd (``Delay'') to cope with this. At 
the same time, though, the CPU will be pretty much idle in all the other audio 
callbacks.
If we could spread the load of the expensive, but occasional, computation (say 
fft) over multiple audio callbacks, then the CPU load would be more even, with 
no spikes and there would be no need to increase Pd's internal buffering.This 
would require to have the output of the fft available a few processing blocks 
after the one where it was started, while the current approach allows to have 
it immediately available. A fine tuning of the system would be required to 
understand how much this latency should be, and worst case it would be the 
number of overlap samples as set by [block~] (as in: if the system cannot 
process these blocks fast enough, then you should lower your requirements, as 
your system cannot provide the required throughput). Now this may seem a 
downside, but the actual overall roundtrip latency of the Pd subpatch would be 
<= the one currently achievable, with the added advantage that the rest of Pd 
could work at smaller blocksizes and without the additional ``Delay'' required 
in the current configuration.The ultimate advantage would be to have a more 
responsive system, in terms of I/O roundtrip for most of the patch, except 
those subpatches where a longer latency is imposed by the algorithm. Think for 
instance of having a patch processing the live the sound of an instrument, 
which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A 
low roundtrip latency could be used for the processed instrument while the 
latency imposed by [sigmund~] would only affect e.g.: the parameters of the 
effect. I see how this approach may be useful in many cases.Multi-core hardware 
would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] 
for use with libpd on Bela which works fine and I am wondering if it is worth 
going down the route of making threaded versions of all objects with similar 
requirements (which I really would not want to do) or I should rather try to 
create some higher-level objects (say [blockThread~] ) that perform the 
threading strategy mentioned above.It may be that [pd~] could probably(?) 
provide the solution requested, but it seems to me there is lots of overhead 
associated with it, and I do not see how to easily integrate it with our use of 
libpd.
So, probably this point has been discussed previously, I'd like to know:- are 
there any existing objects doing this already?- what are the pitfalls that 
prevented such an approach from making its way into Pd?- how can I help?
Best,Giulio
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to