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