[PD] sanity check on workings of pd~

cyrille henry ch at chnry.net
Wed Apr 6 22:40:11 CEST 2016



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 <mm.markidis at gmail.com> 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 <brbrofsvl at gmail.com <mailto:brbrofsvl at gmail.com>>:
>
>     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 <msp at ucsd.edu <mailto:msp at ucsd.edu>> 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
>          >
>
>          > _______________________________________________
>          > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>          > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
>         _______________________________________________
>         Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>         UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
>     _______________________________________________
>     Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>



More information about the Pd-list mailing list