[PD-dev] slowing down dsp function inside perform loop
Thomas Grill
gr at grrrr.org
Wed Dec 6 13:55:18 CET 2006
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.
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.
all the best,
Thomas
More information about the Pd-dev
mailing list