Le 06/04/2016 22:01, Jonathan Wilkes via Pd-list a écrit :
Some more sanity checks: Problem with throwing gem patch in [pd~] is that the block synchronization is way too granular for video processing. In other words, you could have gem object chain calculations that will finish in time to show the next video frame, but they don't finish in the time it takes Pd to compute a 64-sample audio block. This leads to freezes or dropouts in the parent process that is processing audio. Similarly, if you switched roles-- gem stuff in parent process, audio in [pd~]-- you'd still have a problem. While the audio in [pd~] may get computed on time, the video computation in the parent process may take too long. So the audio is sitting there waiting patiently, but the parent doesn't get done with its computation in time to call it by the deadline. Is this essentially correct?
pd and pd~ are syncronize at audio rate, but a buffer allow to control the way to computation of the 2 can be out of sync. i.e : using a fifo of 5 blocks (less than 7ms), the 2 process can't be desynchronized more than 7ms... If the Gem patch and the audio patch can both run in real time on there respective thread, then no process will wait the other if the fifo is large enough. When using Gem in the pd~, i would use at least double the time between 2 images for the fifo buffer. i.e. at 50fps, there is 20ms between images, so i'll try a 40ms buffer. At 48Khz, this represent a minimal fifo of 30. double that for 25fps rendering.
If so, couldn't this issue be addressed by setting a larger dsp-block size for the sub- process?
i don't understand why a larger dsp block size would change anything. did you also do audio computation in the pd~? be also aware that communication between pd and pd~ is cpu hungry. cheers c
-Jonathan On Wednesday, April 6, 2016 3:14 AM, Marco Matteo Markidis <[email protected]> wrote: Hi, me and Matt discussed [pd~] some time ago. The default fifo blocks is 5; anyway (line 634 of pd.c) [pd~] doesn't check arguments, so you can put values as you want, like fifo 0 or fifo -1... but it doesn't like :) Best regards. Marco 2016-04-06 6:22 GMT+02:00 Matt Barber <[email protected] <mailto:[email protected]>>: You can get it down to one block. You can try zero, but it will crash; maybe that's a bug (that is, maybe it shouldn't honor the request with an attempt). The default is five blocks of delay, if I remember correctly. On Wed, Apr 6, 2016 at 12:00 AM, Miller Puckette <[email protected] <mailto:[email protected]>> wrote: It has a specifiable delay in blocks, minimum 2 I believe. cheers Miller On Wed, Apr 06, 2016 at 02:52:10AM +0000, Jonathan Wilkes via Pd-list wrote: > Hi list,Does [pd~] have a one-block delay? > Thanks,Jonathan > > _______________________________________________ > [email protected] <mailto:[email protected]> mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] <mailto:[email protected]> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] <mailto:[email protected]> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] <mailto:[email protected]> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
