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