[linux-audio-dev] [simon at arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]

[Andrew (Andy) W. Schmeder]

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 at a2hd.com>