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

[Hans-Christoph Steiner]

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