Hi Olaf and all,
Yes, DSP and "event" computations have the same priority, and the order in which they are carried out is deterministic (so that DSP doesn't interrupt event processing, for example.) There's only one thread, although nothing stops objects from sprouting their own threads. (but don't call outlet_...() except from the "main" thread!)
Ther's something else wrong with your setup if long computations cause audio to die or Pd to crash. You should be able to call "sleep(5)" from an object and have Pd bounce back after 5 seconds as if nothing were wrong except a DIO error. If this isn't working it's wrong and I'd like to know what audio hardware&drivers you're getting this with...
Sorry, I'm not sure windows has a "sleep" function, substiture a for loop counting to 1000000000 for example.)
cheers Miller
On Fri, Feb 22, 2002 at 07:17:43PM +0100, Olaf Matthes wrote:
Hi Miller, hi all,
I've a question concerning the 'timing' of pd. I once had difficulties to load several soundfiles into arrays using loadbang. Pd reported "audio I/O stuck..." and crashed. A workaround was to delay the loadbang by several ms each before loading the next soundfile. Now I have problems with my oggcast~/oggamp~ externals when connecting to the server via the net. Using a "connect" message sort of stops pd, i.e. audio out stops and goes on after the connection has been established. But sometimes pd crashes reporting the same "audio I/O stuck..." as last message... My question now is if this is due to the architecture of Pd and if there are any ways to avoid it. I allways thought only the perform routine to be time critical but now I begin to realise that everything has to fit inbetween two dsp calls. Is this right? If yes, is there no multithreading inside Pd (in the windows version) to have non-signal routines running in a second thread? (my externals use multithreading just for encoding / decoding and data transmission via TCP since this would halt the performe routine)
Olaf
Miller Puckette schrieb:
There is a problem in that Pd doesn't warn objects properly when they're getting freed... the free() routine gets called right before the object is destroyed adn you don't have a chance to open a save() dialog if you want to save internal state separately. I want to fix that for a future release.
cheers Miller