I think it's fine to have DSP and pollgui, etc., in the same thread
(I hope to improve the relative scheduling of real-time and graphics
by queueing graphics updates but am stuck at the moment on that.)
It seems to be emerging that on most systems at least, setting separate
threads for audio computations doesn't actually improve real-time performance.
On Mon, Jun 02, 2003 at 01:00:34PM -0500, chris clepper wrote:
What's wrong with simply putting a mutex around all of Pd? that way other
threads could just make calls right into "receive" objects without having
to set and wait for clock callbacks. Perhaps I'm missing something but that
seems the much simpler solution for making threaded externs.
Pd's scheduler would simply lock all pf Pd whenever it issues a message or
runs a DSP tick, and unlock it when it ``idles".
Is it not possible to do a mutex thread with the DSP function? Would
this assure that the DSP calls would have enough time to complete
without fighting sys_pollgui() and the other calls for time? Or
would those have to be threaded as well? It seems like when DSP is
on that all other tasks need to be subservient to the computing of
audio to ensure proper audio performance.
It would be really great to have some sort of solution to this within
the Pd scheduler.