Re: [linux-audio-dev] [simon_AT_arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [simon_AT_arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]
From: Tim Goetze (tim_AT_quitte.de)
Date: Sun Mar 28 2004 - 15:09:07 EEST


[Andrew (Andy) W. Schmeder]
>On Sat, 2004-03-27 at 05:24, Tim Goetze wrote:
>> 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).

nice. i've cc'ed this (Simon, do you read l-a-d?).

>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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Mar 28 2004 - 15:21:23 EEST