Subject: Re: [linux-audio-dev] analysis/resynthesis environment: python?
From: Tim Goetze (tim_AT_quitte.de)
Date: Sun Aug 18 2002 - 20:02:37 EEST
Hi Brian,
hope you don't mind me putting this on-list again (and replying to
myself ...).
>I wonder about using python (or java) just to drive midi control signals
>to a softsynth like iiwsyth to sequence soundfonts. It looks like the best
The package I'm working on does just that, among other things. Release
date unknown, GPL en tout cas.
[...]
me wrote:
>> I'll probably implement a different solution, that is to run the C++
>> core at low latency, collect 'n' cycles of audio signal and pass those
>> in one array to a Python DSP prototype. This would be adding n * (core
>> frames/cycle) to the processing latency.
>>
>> If you're brave, don't have other Python threads holding the BPL (Big
>> Python Lock ;) and have a very simple DSP routine, you might get away
>> with setting 'n' to one.
Unfortunately not, I've done a basic implementation yesterday.
At 128 / 44.1, mmap'd ALSA, ice1712, a halfway reliable setup is
'C++: pink noise, mono' ->
'C++: collect 4 cycles into one buffer' (= 512 frames) ->
'C++: notify Python thread' ->
'Python: apply gain to buffer' ->
'C++: play buffer'
For stable operation, the buffer needs to be played at least 256
frames later. More complicated algorithms will probably require more
latency.
Using NumPy and more MHz (450) might help bringing the latency down. I
doubt there's a lot left to be gained though; the Python thread was
run SCHED_FIFO, second in priority only to the audio thread, Python
was told to release the interpreter lock every 1e+9 instead of 10
bytecode instructions, with the main Python thread asleep in
interactive mode. Suggestions for better performance are welcome.
However for prototyping DSP algorithms it may prove a nice feature I
think.
tim
This archive was generated by hypermail 2b28 : Sun Aug 18 2002 - 20:01:44 EEST