[PD] sanity check on workings of pd~

[Jonathan Wilkes]

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?
If so, couldn't this issue be addressed by setting a larger dsp-block size for the sub- 
process?
-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>:

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> 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 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



_______________________________________________
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


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160406/755b7050/attachment-0001.html>