Reply by Martin Eisenberg August 2, 20052005-08-02
Instead of dealing with interrupts, you might write plugins for a 
LADSPA host. Also take a look at graphical languages like Pure Data 
or jMax where you can build a realtime DSP graph and write extension 
blocks of your own. 

http://www.ladspa.org/
http://www-crca.ucsd.edu/~msp/software.html
http://freesoftware.ircam.fr/rubrique.php3?id_rubrique=14


Martin

-- 
Quidquid latine dictum sit, altum viditur.
Reply by chuckles August 2, 20052005-08-02
Hullo,
    I've been tinkering with the Alsa library api and C++ dsp for some
time now. Up to now I have used temporary files stored on a tmpfs when
working with samples (not individual samples, 'samples' that are 30
seconds of music etc.). I had originally planned to try and implement
some sort of real time audio processing. I decided to try jack, updated
my kernel to 2.6.12 and added a few low latency/real time scheduling
patches. I could not get jack to work right, I could get the latency
down to about 10.8 ms but the signal is so corrupt as to be totally
unuseable (any lower and xruns wipe out all audio). Would there be any
benefit in attempting to right my own assembly ISR to retrieve sound
data for processing. I have done some assembly in my undergraduate
years (not real world assembly embedded in C or the like, more simple
algorithms developed and optimized on toy processors) and had some
sucess with writing reasonably fast assembly code but I'm not sure it's
worth the effort. Is jack a good indication of real time processing
possibilities for my particular set up or could a few tightly rolled
assembly routines make all the difference? If anyone who has some
experience in this particular area could offer an educated opinion
that'd be great.

Cathal