Subject: Re: [linux-audio-dev] [simon_AT_arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]
From: Tim Goetze (tim_AT_quitte.de)
Date: Sat Mar 27 2004 - 15:24:15 EET
[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
This archive was generated by hypermail 2b28 : Sat Mar 27 2004 - 15:28:56 EET