Out of curiosity, whats is callback scheduling ? (:

++

Jé

Tim Blechmann a écrit :

...

The only major new "feature" in 0.41 is callback scheduling;

out of curiosity, i had a brief look at the code ... two comments ...

• has the support for the system lock been dropped for the callback

scheduler?

• is it intended that the sys_idlehook is called from the main thread

without any guard?

best, tim

-- tim@klingt.org http://tim.klingt.org

Life is really simple, but we insist on making it complicated. Confucius

---

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Cool,

Maybe pd's on its way to a lower latency audio-processing tool then ?

I remember an old thread in which Tim used to say that, as it is, pd is by design not very a efficient real-time piece of software. IMHO, this is quite satisfying but if it could get better... wow.

Thank you all for keeping up with the good work !

++

Jé

Thomas Grill a écrit :

Am 28.12.2007 um 20:15 schrieb Jerome Tuncer:

...

Out of curiosity, whats is callback scheduling ? (:

It means that DSP processing is done directly in the audio driver callback without using a separate ringbuffer in PD. This allows for much lower audio latencies. gr~~~

Am 28.12.2007 um 20:25 schrieb Miller Puckette:

I should have put the lock in and forgot... thanks for the reminder.

I'm not at all sure how to handle "idle" in the callback case. One could just call the function forever, but that seems like burning the CPU for nothing.

You might have noticed that the idle callback function in pd-devel
returns 0 (when it never wants to be called again), 1 (when it wants
to be called again as soon as possible) or 2 (when it wants to be
called again at the next scheduler iteration). This works pretty well
and helps to preserve cpu.

Alternatively, "idle" processing might want to take place in a different thread to be set up by whatever external code wants to do the idle processing, trusting to the OS to preempt to the callback thread when it becomes runnable.

It's a cleaner approach given the fact that the functionality allowed
within the audio driver callback is limited, but it involves locking
which isn't nice.

gr~~~

Miller Puckette schrieb:

Well, if in callback mode, the non-interrupt main loop is also in a different thread from the audio (if I understand correctly) and so there shouldn't be any difference between adding stuff to Pd's "main" thread and adding other threads. I think the locking considerations are the same too.

So it's probably adequate just to have the callback scheduler obtain the "global lock" and let externs add whatever they want as separate threads.

Hmmm, i guess you are right. I think however that it's a good idea to keep the number of threads accessing the PD API by using locks small. In flext there's one general helper thread (or idle callback function, depending on the PD API version) forwarding messages from threaded externals to the PD kernel (messages via senders and outlets), employing a lockfree fifo. This can also be done in PD style standard C by use of the fifo mechanism in pd-devel as implemented by Tim Blechmann.

Come to think of it, that also would remove the need for an idle() function in case one is using the polling scheduler too, no?

I think so... by the way, has anyone used the idle function as it is in standard-PD?

gr~~~