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.
Christof
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 !
Best,
ffdd
On Thu, Sep 24, 2020 at 5:42 PM Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
That _should_ be correct. fifos less than 2 are probably inefficient (but I dn't know that for sure). cheers Miller 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@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!Uyv-HqXmCoj0l9209QG7_r5nfJVd8i8hyj0jSDRm6FzZv6t-9DKLtwT6Zaba$-- fdch.github.io http://fdch.github.io
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list