[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