Le 24/11/2012 05:44, puredata@11h11.com a écrit :

it's working but i have a major "party breaker":

[pd~ start -rt -nosleep -nogui bgAudio.pd< | [pd~ -ninsig 2 -noutsig 2]

[pd~ start -noaudio -nrt bgVideo.pd< | [pd~]

= glitches in sound when pushing GEM. using 2 instances of pure data (with the same options) i don't have any glitch, of course the fps is slow but the sound is intact.

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.

what am i doing wrong here? i would like to use this setup (avoiding communication with netsend and starting manually 2 instances of pd).

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 c

thx

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Le 24/11/2012 05:48, puredata@11h11.com a écrit :

a screenshot: https://dl.dropbox.com/u/1455235/bg.png

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)

cheers c

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Le 25/11/2012 19:53, puredata@11h11.com a écrit :

i will not be able to use [pd~], i need a stable audio output no matter what is happening with gem. i know nothing about [pd~] but would it be possible to add an option -nowait or -nosync (making [pd~] independent)?

this is agains pd~ phylosophie. use 2 pd.

...

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)

compiled and tested successfully, but i am wondering if i could use this external instead of netsend/netreceive with 2 instances of pd?

yes.

cheers c

thx