[Simon Burton] >I stopped coding when I could play/process arrays of sound from >within the portaudio callback. Yes, PA calls back into python, >acquires the Big Bad Lock, and all that.
ah, thanks for drawing the curtains. may i suggest a solution? (background: i'm working on a similar project, which revolves around C++ for RT audio, but also allows 'soft-RT' python audio.) i've decided not to mess with either python locking or its memory allocator. instead, an asynchronous scheme is employed: C++ RT audio callbacks write to a lock-free FIFO and signal there is sample data to process (this is done by writing a trigger to a UNIX pipe on which the python audio thread sleeps). a second FIFO holds the results of python audio processing. the callback code doesn't wait for the python DSP code to complete, instead it fetches processed data from the second FIFO right away and returns to Jack/PA/the LADSPA host/your native audio code. all this is possible without acquiring any locks. of course, this introduces latency in the signal path (at least one cycle worth). otoh, the scheme runs free of dropouts, especially if latency is allowed to span multiple audio cycles, and is compatible across python versions. >Thanks Tim, I asked around on the PA list also, but you have >given me some more directions to persue. Also I gather that >SuperCollider is another place to look for RT audio implementation. SuperCollider sure is a nice design. unfortunately it's not using python. :) yet, making python RT-friendly really is too daunting a task for a feeble mind like mine. cheers, tim