28 Mar
2004
28 Mar
'04
9:20 a.m.
[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