Re: [linux-audio-dev] Re: costs of IPC

[Paul Davis]

>> and its not as bad as you think, since programs like software samplers
>> will likely be feeding audio data from disk into a ringbuffer. even
>> though the ringbuffer may be large, each invocation by the engine will
>> only touch a fairly small amount of it.
>
>Mmmm, yes. I was wondering about that. It's abviously bad for the DSP
>parts to do the loading form disk, so what is going to, and how is it
>going to feed that data to the DSP part?

Well, Ardour does this via a lock-free ringbuffer. There's another
non-RT-scheduled thread that does write-behind and read-ahead to the
ringbuffer. Evo has a similar design, and ecasound too I think. We've
talked about this a lot here.
 
>> i don't know enough about convolution and other DSP algorithms to
>> sense their memory footprint. do you have any thoughts?
>
>Not loads, probably a meg or two, but half of it will get polluted on each
>invocation. 

You're going to touch 500kB plus to process 64 frames of audio data?

--p