signal processing - Effects processor: Thoughts about software architecture, choice of programming language, API -

i'm working on project major element piece of software can signal processing in real-time.

the basic idea/concept following. audio data captured continuously (usb) audio interface (running @ 96 khz, 24 bit). run through "processing chain" (like "virtual effects chain"), each element can perform arbitrary processing on data. data handed 1 element next, until arrives @ sink. data flows sink sent audio interface output.

the signal chain consists of "objects" implement "processing" method, works on chunks of data of 1920 samples (20 ms) size (though 1 might change number).

the basic idea in "pseudo code".

while (true) {    float[] samples = audio.read(block_size);     foreach (effect e in signal_flow)       e.process(samples);     audio.write(samples); } 

a first prototype has been implemented in python uses alsa api audio i/o. 3 separate threads started.

the first 1 continuously reading alsa (which blocking operation) , puts data queue, goes on reading next block. (alsa requires me "read(...)" @ least every 20 ms, need lightweight thread that, nothing read , store data, can meet time constraints.)

the second 1 reads samples input queue, puts them through signal chain , queue output.

the third thread reads output queue (which blocking operation) , writes blocks out alsa.

i have 2 "numeric" variables here, 1 being block size , other being number of blocks "pre-post" output queue before begin processing, gives me time "deliver more samples" without output buffer underrunning. in addition, can decide these things either in separate threads or in separate processes.

after serious debugging (which involved use of both signal generator , oscilloscope!), got approach running. biggest problem bug in alsa api, namely "period_size", specified "the number of frames read/written" appears number of frames read, number of bytes written. when specify 1920 (20 ms of audio @ 96 khz sampling rate) both, input , output, 1/4 of output, 3/4 of silence, 1/4 of output. when specify 1920 * 4 = 7680 both, input , output, error device's buffer not large enough read many frames. when specify 1920 input , 7680 output, works (and queues not "overfill" either).

having solved, have 1 serious problem left , is: latency!

i started entire project in order create own effects, want software operate effects unit stage/live use. i've read when 2 events less 30 ms apart, e. g. 2 strobe lights fired 30 ms apart, human brain can no longer tell 1 first , second. delay of 30 ms or less percieved "instant". it's threshold events "merge" , percieved "one". if latency low, couldn't tell event first, e. g. guitarist no longer tell, if struck string , sound came pa or if sound came pa , struck string, feel "zero latency" , real amp.

now latency have arrived @ ... ... didn't have opportunity measure them yet, it's in order of tenths of second, 200 or 300 ms. it's far much! tried both separate threads , processes i/o (since in python never know if threads gonna faster due "global interpreter lock") , processes slower, expected, due overhead associated inter-process communication , fact 2 i/o processes don't "intensive". wait on blocking operations , perform fast i/o.

as remark, want application host web server (of course in separate thread or process) allow user configure signal path , adjust parameters effects "devices" in intuitive way.

so need latency down! have several paths follow now.

1. my first idea replace alsa jack, said "low-latency". drawbacks lose control on exact levels @ adc/dac (jack works floats, scaled [-1.0, 1.0], no matter hardware does) , on sampling rate (as far know, jack "dictates" sampling rate - can no longer chose - alsa select sampling rate want work , transparently upsample/downsample me if hardware deviated that), blocking i/o (that find pretty nice paradigm) replaced callback mechanism , timing constraints harder meet. (i cannot "buffer" on own jack. requires processing done in amount of time.) also, jack api appears more complicated in general, alsa api. replace alsa jack, i'm not sure how "win", given alsa pretty "low-level" api , jack builds upon, uses in specific way keep latencies low. honest, i'm not sure how of latency due alsa , "below" , how due "higher layers".

2. i make use of interpreted, garbage-collected language. that's bad real-time requirements. alternatives? well, of course c comes mind when thinking real-time applications, there serious drawbacks.

2.1 - want software have web-based ui. creating web server in python simple. there's class in python standard library. creating web server in c pain. there's nothing in c "web". i'll have start scratch based on nothing socket api. luck! :-(

2.2 - python has support numerics. has numpy , scipy , therefore vector data types, matrix multiplication, fast fourier transform, fast convolution, interpolation (splines, etc.). useful problem @ hand here. in c, lose this, means either have job done without, unlikely, or i'll have recreate of on own in c, both time-consuming , error-prone.

2.3 - python has "high-level" support multiprocessing , multithreading. can communicate between processes , threads via synchronized queues, implementing solution in "thread pool / replicated workers"-style fashion, extremely useful paradigm problem @ hand here. in c, i'll have resort posix threads , low-level synchronization primitives mutices. (is correct plural "mutex"? in "unix" --> "unices"?) again, both time-consuming , error-prone.

any suggestions on languages use? languages i'm familiar include python, c-sharp, java, c, go, little bit of c++ (i never need language - either it's low-level, use c, or it's high-level, use garbage-collected, interpreter or bytecode-compiled language), , web technologies (especially javascript ajax, etc., useful when comes ui).

all of has to run under linux distribution, preferably little dependencies / libraries possible. "standard" libraries preferred on "exotic" ones. platform-independance, ability run under windows, plus, not strictly requirement.

i'm ok ui being implemented in different language (go web server comes mind) actual processing (which might "have done in c" if needs real-time?), though brings lot of complexity, both run in separate processes , communicate via, say, unix domain sockets, requires data passed , forth represented byte stream (since that's socket transports), 1 needs design inter-process communication protocol , lots of parsing @ level well. chance avoid huge overhead , in single language?

any other ideas? specifically, gain going alsa jack? there other alternatives haven't considered yet, might suit task better?

thanks lot time!