Subject: Re: [linux-audio-dev] a new application underway
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma loka 11 1999 - 21:39:02 EDT
>> i'm still working on optimizing the amount of data copying that goes
>> on in a net like the one above, but it all works just fine for
>> now. MIDI controllable control elements too :)
>
>VST uses the process() and processReplacing() plug-in calls as a
>part of that optimization. I suggest process() to be our replacing
>method, and process_mix() to add data to the output buffers. The big
>difference: process_mix() is *required* to support a linear gain
>parameter for each output channel.
>
>But, is the cost of clearing a buffer really significant these days,
>when some plug-ins can eat a whole P-II 400 using a single instance?
this is not the cost.
specifically, i'm looking at a situation where i've got N channels of
interleaved data read from a soundcard, sitting in a buffer. a mixer
strip picks up 1 channel from this buffer, and mixes it into 1 channel
of the output buffer.
the simplest way to route input to output would be to have each node
in the processing net act like a proxy, and have it additively combine
the relevant (think interleaved) data from the input buffer with the
relevant (again think interleaved) data of the output buffer.
i say proxy because i'm talking about using function calls that hide
the additive combination. this prevents the node from seeing the data
that constitutes its input.
it can do this if the only thing to be done to the data is to scale it
(think volume and panning) - we just pass the scale factor into the
additive combine function. In many common cases of mixing, this is
all we will be doing.
but even in the common cases, we'd like to know, for example, the RMS
level of a strip's input. if it only has the mix function, it has to
compute the RMS level of the output buffer beforehand, then recompute
it again after the mix. not good.
so, this is what i'm carefully considering how to avoid in a
multitrack mixer.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST