Subject: Re: [linux-audio-dev] a new application underway
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti loka 12 1999 - 11:15:59 EDT
>Hmm, most plugin/effect designs seem to be based on copying from
>input buffer, processing and writing to output. I've always
>done processing in-place (effects get a pointer to the sample data).
>Am I missing something here?
if the plugin/effect can do simple pointer walks through its input
buffer, then what you describe will always work. but if the original
data source has interleaved channels (as many do!), and the plugin is
only working one channel, then you either have to (1) first copy the
channel data into a single non-interleaved buffer or (2) provide a
special function that understands how to walk through the interleaved
buffer or (3) make the plugin understand that.
these all have their costs. (1) implies a data copy (2) prevents the
plugin/effect from looking directly at its input data which prevents
certain things from being done and (3) seems like poor, though not
unworkable design.
so for me, the choice is between (1) and (3). In (3), we'd pass a
"pointer increment" argument to the plugin, telling it how far its
data pointer should increment each time it is moved in order to stay
in the right channel. Then it can do:
for (ptr = input_buffer; ptr < input_buffer_end; ptr += pointer_increment) {
... process *ptr ...
}
this avoids the data copy.
on the other hand, since its likely that the input data will not be in
the right format (e.g. we want to use 32 bit floating point, and the
data arrives as 16 bit integers), we normally *have* to do one data
"copy" anyway (of course, it isn't a copy per se).
so it may all come out in the wash ...
--p
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST