[PD] pd~ fifo flag and block delays
info at christofressi.com
Fri Sep 25 03:32:26 CEST 2020
I think that having a small buffer for the subprocess is not a problem,
as long as the buffer (= delay) of the parent process is large enough to
absorb the CPU spikes of the subprocess.
If you use a single buffer for the subprocess, then the parent process
practically has to absorb all CPU spikes.
Of course, it depends on the actual patch. For example, if the
subprocess has several large FFTs (which are notorious for producing CPU
spikes), it makes sense to use a higher buffer size to prevent it from
blocking the parent process. If the subprocess has a fairly regular CPU
load, you can get away with the minimal buffer size, even if the parent
process has a rather small buffer size.
On 25.09.2020 00:41, ffdd cchh wrote:
> Thanks, Miller.
> Yes, it seems that is the case. I attach an example that shows the
> delayed block(s).
> What do you mean inefficient? I do not see a drastic change in cpu
> usage on the very basic adc-to-dac example subprocess I include here.
> As a side note, I noticed that loading -fifo 0 seems to crash pd !
> On Thu, Sep 24, 2020 at 5:42 PM Miller Puckette <msp at ucsd.edu
> <mailto:msp at ucsd.edu>> wrote:
> That _should_ be correct.
> fifos less than 2 are probably inefficient (but I dn't know that for
> On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote:
> > ???Hi,
> > When using pd~ with -fifo 1, do you get a delay of 1 block like
> in throw/catch scenario?
> > Thanks!
> > fd
> > fdch.github.io <http://fdch.github.io>
> > _______________________________________________
> > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> > UNSUBSCRIBE and account-management ->
> fdch.github.io <http://fdch.github.io>
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list