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