[PD-dev] slowing down dsp function inside perform loop

[Eric Lyon]

Thank you Thomas, hc and others for helpful feedback. The function I'm
deferring is doing asynchronous DSP, not messaging. Essentially a barrage of
intensive DSP thrown at the contents of a buffer (array in Pd land) that
will hopefully be done in time to be played back in the main perform loop.
Actually a lot of it is working on Pd now, but there are a few functions
that do reliably crash Pd, even though they're not CPU-expensive. Quite
possibly some memory indiscretion. I'll report back on any further findings.

Best,
Eric



>
>
> On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote:
>
> > On Wed, 6 Dec 2006, Thomas Grill wrote:
> >
> >> currently there's no low-priority messaging in Miller's pd
> >> version, but there is in the devel branch. It's one of the
> >> features that have been there for some time and i'm trying to
> >> provide a patch for Miller, so that it can make it into vanilla PD
> >> some time in the future. Hopefully the auto-discard mechanism of
> >> the patch tracker will blow up before that time. Don't expect the
> >> feature to be available soon.
> >
> > So, how does one use that feature?
> >
> > Is it that all the audio is high-priority and all the non-audio is
> > low-priority?
>
> Isn't that basically the way it is now?  Correct me if I am wrong,
> but isn't audio data processed first in each cycle, then message data?
>
> FYI: Max since 4.3 (I believe) has two audio threads, a high priority
> and a low priority.  "qelems" and the defer() functions give you
> access to the low priority thread in externals.  Another detail of
> not is that the threads are cooperative, not pre-emptive.  If a give
> process doesn't defer(), then it won't give up that thread until its
> done processing.
>
> .hc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20061206/caa87ad1/attachment.htm>