Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: David Olofson (david_AT_gardena.net)
Date: Fri Feb 09 2001 - 13:10:10 EET
On Friday 09 February 2001 10:46, Richard Dobson wrote:
> It's interesting to me read about 'the kind of plugins LADSPA is
> meant for'. I would like to know more about this. I need to do both
> de-interleaved processing (for my real-time pvoc processing) and
> 'wide-buss' interleaved processing, such as handling Second-order
> B-Format data (nine channels!). But even in the pvoc work, the
> analysis frames are interleaved by audio channel. Overall,
> interleaved data seems much more generic, and real-time friendly.
Yep, indeed - as long as you get the data in the format that the
plugin expects. If you have to convert/(de)interleave, you get extra
memory copying as well as cache problems caused by the non-contiguous
access patterns.
> Is it really such a performance-killer - the time to [de]interleave
> data is a knats-p in a millpond compared to doing 600+ FFTs in
> real-time...
Well, yes. Same goes for API overhead, and even for conditional
checking of things, as opposed to the first impression most people
get when looking at an API.
For example, LADSPA may look faster than MAIA when considering that
LADSPA just shares variables where MAIA has to use timestamped events.
However, what happens when you realize that you have to check all
those shared variables for changes every time you call run()? (You
must interpolate virtually all control data to avoid clicks and pops.)
And what happens when you need more accurate timing than the engine
buffer size? Right, you have to process "short buffers", which means
that the plugin has to be called extra times (not *that* bad) - and
that the plugin has to do the pre-loop initializations (and the
control port checking!) for every one of those calls.
It might be that checking a single event port once per process() call
+ once per event during the buffer isn't all that bad after all...
Back to the original topic; it might not be that bad to use pitch
values for all Buffer Slots. (Or audio ports, as LADSPA calls them.)
It does hit performance with an extra add from a variable when the
pitch == 1 frame, but how does that compare to doubling the amount of
non-sequential memory accesses, and then adding an extra memory copy
when pitch != 1 frame?
I don't have the statistical data to tell for sure, but then again,
I'm not sure the pitch even imposes a measurable performance impact
on any real DSP plugin. If no, why even consider leaving it out?
//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 |
`--------------------------------------> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Fri Feb 09 2001 - 13:22:28 EET