Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 03 2001 - 23:50:34 EEST
>- It might be nice to have access to multiple channels with one call -
> i.e. request_channels, write_channels, read_channels, etc.
the model is 100% non-interleaved audio. you never have more than one
channel to process at once, and there is zero speed benefit from
passing several in, since they all need to be processed one by one
anyway (again, since the model is 100% non-interleaved audio).
>- Is there a reason not to use size_t instead of guint32? It seems like
> it would be nice for these values to be larger on those platforms where
> a larger value might be more efficient.
its a toss-up. size_t is defined as the maximum size of an OS object,
so its an undefined 2^(architecture-bits). guint32, by contrast, has a
defined range. its not clear which one is better. i opted for the
defined range.
>- It is not clear from this whether the plugins are required to be the
> equivalent of run adding - that is can they simply write over the buffer
> that is filled with read_from_channel call or do they have to add to the
> buffer?
they are neither.
the whole point of request_channel() and release_channel() is that the
setup some internals in the server so that calls to
read_from_channel() and much more importantly write_to_channel() do
the right thing. that is, the server takes care of the
"run"/"run_adding" semantics for us. the plugins have no idea what
they're doing except sending data to a channel. this is in marked
contrast to VST and LADSPA.
>The last point seems important to me. My overall question is one of
>amplitude normalization - if plugins normalize their output to -1 to 1 and
>two plugins write to the same channel then the server would need to scale
>the output. Is this what happens in your system now? What happens when a
>plugin is removed - is the scaling reduced causing a big jump in volume
>for the user? If there is no scaling how is clipping avoided? Otherwise
>this looks great.
there is no scaling. we do unity-gain mixing (well, actually, we allow
scaling by the plugin when it calls write_to_channel() c/o the gain
argument to that function, but the result is mixed into the channel at
unity gain).
if the summed amplitudes on a channel exceed 1, then its clipped. this
is digital audio, remember ? :)) this is just an attempt to model what
would happen in hardware.
if you want a different effect, you send all the plugins onto an
internal bus, and then have a plugin that reads from the bus, scales
the amplitude by a user-adjustable (or automatic?) factor, and then
sends it to the physical channels. the internal bus is float
throughout, so you'll "never" cause clipping on that level.
--p
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 00:17:55 EEST