Hi, I have a question concerning the [pd~] object:
How can I benefit from using it? I'm quite confused.

I did a test running a very cpu hungry patch in a sub-process and putting a reverb in the super-process. My preconception was that the audio drop-outs would occur only in the sub-process and could be heard in a nice clean reverberated way, but it affects everything, I have audio drop-outs wether I move objects with the mouse in the super-process or in the sub-process.
When I checked the cpu load was 90% in the sub-process and 10% in the super-process.

Is that related to the way JACK works? or a computer? Please excuse my complete ignorance on the matter.

I'm running ubuntu 14.04 with JACK on a Intel® Core™ i5-5200U CPU @ 2.20GHz × 4.

Allister

@allister Hi,
Had a similar question a way back:
http://markmail.org/message/r5ds4ebusmfdbkrw?q=puredata%4011h11.com+list:at.iem.pd-list#query:puredata%4011h11.com list%3Aat.iem.pd-list+page:1+mid:orbik7b2ksdk2wht+state:results

In short:

what is the -fifo option of [pd~]?

this is an important option:
it set the delay (in audio block) between pd and pd~.
since pd and pd~ are syncronize at audio sample rate, if the fifo is small, any
blocking operation in pd~ will block pd.

so, if your GPU can't compute more than 20fps, each frame need about 50ms to
compute. So the fifo must be more than 50ms. somthing like 40 block is a minimum
in this example.

moreover, you have to be aware that pd / pd~ communication is inefficient, so
cpu is higher using pd/pd~ than using 2 pd.
(that the reason of the share_mem lib)

The aim of pd~ is to synchronize different thread. so if your ask Gem 20fps, but
only 10 can be computed, then one pd~ is not realtime, the other pd~ will have
to wait to be synchronize. No correct sound ca=ould then be computed.

if one of your patch use more than 100% cpu, it will also pause the other patch.
in this situation you should not use pd~

Cheers~

Hi @EEight,
Thank you for your reply! Seems it is not what I'm looking for