On Wednesday 07 February 2001 17:29, Richard Dobson wrote:
> Having already taken a quick peek at the source, I have one
> fundamental suggestion - don't hardwire assumptions of stereo
> anywhere, such as "int channelL, channelR". Even if it only
> supports stereo now, which is fair enough at an early stage of
> development, so long as the code can deal with nChannels, the
> project can grow easily and organically. Stereo-only systems will
> be all but obsolete in a year or two!
Speaking of stereo, after doing some more detailed design and
Protocol definitions for MAIA (the Stream Protocol; meant for
varispeed streaming, direct-from-disk sample playback and the like)
I'm considering adding transparent support for interleaved data to
the Buffer Protocol (LADSPA style audio ports) as well.
I'm just wondering if there's any practical experiences among hackers
here regarding this. Right, getting interleaved data when you want it
in separate buffers and vice versa is a performance killer, but what
kills more performance of using pitch variables or (de)interleaving
or converting buffers in external plugins?
In code, I'm talking about
in_s = out_s = 0;
in_pitch = <get pitch for in>;
out_pitch = <get pitch for out>;
while(frames--)
{
out[in_s] = ... in[out_s] ...;
in_s += in_pitch;
out_s += out_pitch;
}
rather than
s = 0;
while(frames--)
{
out[s] = ... in[s] ...;
++s;
}
More additions and more variables, right, but how much DSP code can
you squeeze in before you have to fetch the variables from the stack
frame anyway...?
Anyway, why do this?
Well, there was a rather long thread on interleaved data vs separate
buffers way back, but the issue wasn't really resolved. IIRC, we just
concluded that the kind of plugins LADSPA is meant for generally
don't deal with wide busses, like entire mixers and the like, so the
speed advantages of interleaved data would be seen by few real
plugins.
This may or may not be different with MAIA; I just want to make sure
we're not throwing away a feature that provides transparent support
for interleaved data (without converter plugins) because it *looks*
like it could add some overhead...
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
