27 Mar
2004
27 Mar
'04
9:35 a.m.
[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
27 Mar
27 Mar
11:41 p.m.
New subject: [linux-audio-dev] [simon@arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]
On Sat, 2004-03-27 at 05:24, Tim Goetze wrote:
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.
For what its worth, I have written a python module for jack which works
almost exactly in this manner. (GPL; online at
http://www.a2hd.com/software).
In my implementation the audio buffer, on the Py end, is a numpy array
of type 'f'. When python is not able to keep up, either InputSyncError
or OutputSyncError will be raised by the process call (depending on
which FIFO had an underflow).
Unfortunately python does not appear to be sufficiently fast for any
significant realtime work, in my experience its far less useful than one
might imagine.
--
Andrew (Andy) W. Schmeder <andy(a)a2hd.com>
28 Mar
28 Mar
9:20 a.m.
New subject: [linux-audio-dev] [simon@arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]
[Andrew (Andy) W. Schmeder]
On Sat, 2004-03-27 at 05:24, Tim Goetze wrote:
nice. i've cc'ed this (Simon, do you read l-a-d?).
all this is possible without acquiring any locks.
For what its worth, I have written a python module for jack which works
almost exactly in this manner. (GPL; online at
http://www.a2hd.com/software). In my implementation the audio buffer, on the Py end,
is a numpy array
of type 'f'. When python is not able to keep up, either InputSyncError
or OutputSyncError will be raised by the process call (depending on
which FIFO had an underflow).
to be honest, i don't know much about the numpy implementation. is it
a C extension, coded in python, or hybrid? extensive calculation runs
are terribly slow when done in python to be sure. simply applying gain
in realtime brought my old k6-450 to almost full load.
(the py extension here implements dedicated data types for sample
buffers and some basic DSP algorithms, both doing the number crunching
in-place, in C++. the RT data passing mechanism can be made to
increase latency dynamically, so after a few dropouts at the start of
processing it runs smoothly -- if the box can handle the load at all.)
Unfortunately python does not appear to be sufficiently
fast for any
significant realtime work, in my experience its far less useful than one
might imagine.
pyjack performance might benefit a bit from replacing the data passing
via sockets with locally allocated sample data FIFOs i guess. saves
you at least two data copying passes across kernel per audio channel
and python audio cycle.
agreed about the reduced usefulness of python in an ambitious realtime
audio context like Jack however.
for audible DSP prototyping, instead i'm reading files for input (if
the algorithm wants input), feeding a simple mono/stereo out with huge
(order of seconds) buffering. thanks to the mostly native/C++
processing and the recent acquisition of this 1.7 GHz box, i have yet
to see this scheme run into performance problems. and it lets you
concentrate more on the algorithm coding itself.
cheers,
tim
4:10 p.m.
New subject: [linux-audio-dev] [simon@arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]
On Sun, 2004-03-28 at 04:09, Tim Goetze wrote:
to be honest, i don't know much about the numpy
implementation. is it
a C extension, coded in python, or hybrid? extensive calculation runs
are terribly slow when done in python to be sure. simply applying gain
in realtime brought my old k6-450 to almost full load.
numpy is a c extension, so when you say 'a+b' the heavy lifting is in C.
using numpy is similar to matlab/octave.
unlike the python list, the numpy array stores only numbers, and you can
specify the type. unfortunately a lot of operations require recasting to
double (supposedly fixed in the new version).
(the py extension here implements dedicated data types
for sample
buffers and some basic DSP algorithms, both doing the number crunching
in-place, in C++. the RT data passing mechanism can be made to
increase latency dynamically, so after a few dropouts at the start of
processing it runs smoothly -- if the box can handle the load at all.)
that sounds like a good idea.
pyjack performance might benefit a bit from replacing
the data passing
via sockets with locally allocated sample data FIFOs i guess. saves
you at least two data copying passes across kernel per audio channel
and python audio cycle.
hmm, yes there is room for improvement.
agreed about the reduced usefulness of python in an
ambitious realtime
audio context like Jack however.
recently i have found python/numpy useful for unit testing, though.
basically you write the code in C, wrap it with swig and then use numpy
to validate it statistically.
--
Andrew (Andy) W. Schmeder <andy(a)a2hd.com>
7573
days inactive
7574
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Andrew (Andy) W. Schmeder -
Tim Goetze