On Dec 6, 2006, at 7:55 AM, Thomas Grill wrote:
Am 06.12.2006 um 04:21 schrieb Hans-Christoph Steiner:
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?
The order is like that, but if you have too much DSP operation you
will get clicking, and vice versa, when you have too much message
operation, the DSP tick can't be done in time, underflowing your
DSP output ring buffer.
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.
I'm not sure about that cooperativity. I'm not aware that an
external must do a defer so that another low-priority operation can
be done. I'd rather think that DSP, high and low priority threads
are 3 threads with different priority that share a thread lock, so
that only one can be active at a time (but i could also be wrong)
Low priority messaging works in a way that output messages (like
through an outlet or send) do not directly call a function handler
receiving that message (as it currently is in PD), but are rather
queued. The queue is processed and call the proper handler whenever
higher priority threads leave time for it.
Do you know any good resources on Max's threads? I can't find
anything. They seem to be poorly documented in terms of how they are
actually implemented. They probably aren't OS threads or pthreads
since they have tightly controlled timing.
I've only found this, which sheds a little light:
http://www.cycling74.com/story/2005/5/2/133649/9742
I think I misunderstood the defer() stuff. It seems to be optional.
So basically Max/MSP gives you two queues to put your events on: high
and low.
The timing bugs that you run into with the "Overdrive" threads turned
on must be vicious to debug, since the Max language was designed to
be deterministic, but the threading throws that out the window.
.hc
In pd-devel there's a (thread-safe) sys_callback API function which
installs an idle time callback. These callbacks can decide to run
once or multiple times, depending on their return value. The idle
callback queue is processed by the scheduler whenever DSP and
normal message processing leaves time to do so. This works very
well, but only if the idle functions don't consume a lot of time.
If a low-priority thread consume more time, a secondary thread must
be used, but idle callbacks can be used to communicate with the
main pd thread.
The problem for inclusion into pd-miller is that a small
infrastructure of atomic operations has to be included, which
requires some assembler code for generic OS support (though
functions are there for linux, Windows and OSX >= 10.4), which
might frighten Miller, as in the past with SIMD.
------------------------------------------------------------------------
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
