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 <[EMAIL PROTECTED]>
