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

[Mathieu Bouchard]

On Tue, 5 Dec 2006, Hans-Christoph Steiner wrote:
> On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote:
>> 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?

In Pd CANONICAL? where? where? no, there's only one thread. (apart from 
the watchdog and pd-gui and the threads that some externs use)

> Correct me if I am wrong, but isn't audio data processed first in each 
> cycle, then message data?

In Pd CANONICAL that's in the same thread, so it doesn't matter whether 
it's the first in each cycle, because a message cycle can expand and take 
the time allocated to 20 cycles at once. If your soundcard is running at 
48000 Hz and your blocksize is 64, then your block-clock is running at 750 
Hz, which is 25 times the full NTSC video framerate or 30 times the full 
PAL framerate; and then both GEM and GridFlow process each frame in one 
message cycle; I think I remember that PDP can do it differently, but I 
think that most people don't use that feature (?).

> 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.

Ok, that's not the kind of threads that I was thinking about. What is MAX 
doing to keep JITTER from causing audio JITTER ?

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada