Subject: Re: [linux-audio-dev] matrix model vs. memory
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Fri May 18 2001 - 23:55:37 EEST
What seems easiest to me is a LADSPA like plugin to manipulate the gain.
By making it an independent element on the graph it allows the normal
graph sorting to optimize the buffer usage. It is also the most flexible.
The problem is that it is mixing the LAAGA concept with the LADSPA concept
and may present scalability problems in the multi-thread/process model.
It certainly seems like the most elegant solution, howver.
Karl
On Fri, 18 May 2001, Paul Davis wrote:
> in a matrix model for inputs and outputs, each connection associated
> with a gain coefficients.
>
> in this model, whenever a plugin writes to an output, its not actually
> writing to the memory location that someone else will use for
> input. that location is filled "later" by multiplying the contents of
> the output buffer by the gain coefficient(s) and storing the result in
> the input buffer.
>
> as far as i can see, this means that you cannot optimize memory usage
> by sharing buffers between two connected ports. on the other hand, it
> also resolves whether to use "run" or "run_adding" semantics: every
> buffer is unique, so just use "run".
>
> what worries me about the memory use is that the numbers could climb
> fairly quickly. consider the 64-frame period case again. with IEEE 32
> bit floats, thats 64 * 4 = 256 bytes per buffer. Create 3 plugins:
>
> #1: 52 input ports, 26 output ports
> #2: 32 input ports, 32 output ports
> #3: 4 input ports, 8 output ports
>
> thats 154 ports, or 38.5kB of buffer space. this doesn't feel like it
> scales very well for the MP case, where we know memory footprint makes
> even more of a difference than the SP case.
>
> its interesting to think about the graph of frames-per-period and the
> cost of the context switch - as fpp goes up, so does the memory usage,
> and thus more cache/TLB effects. but as fpp goes up, the cost matters
> less since there is more time per period. i wonder which is the
> steeper of the two curves?
>
> still, its a much more flexible model, since it allows independent
> gain coefficients for each port-to-port connection, so it seems worth
> pursuing for the time being. my model for now:
>
> Engine::process (nframes) {
> foreach plugin {
> plugin->copy_data_from_input_ports_to_output_port_buffers (nframes); */
> process (nframes); /* in-place processing on output port buffers */
> /* data is now in output port buffers */
> }
> }
>
> comments?
>
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| mambo.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Sat May 19 2001 - 00:54:21 EEST