Re: [linux-audio-dev] LAAGA - how are we doing ?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Fri May 04 2001 - 00:16:41 EEST


On Thu, 3 May 2001, Paul Davis wrote:

> >- 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).
>

I was assuming non-interleaved and was not suggesting this for efficiency
(though there is the small speed saving of function call overhead). This
is purely an ease of use suggestion (though of dubious quality).

> >- 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.
>

Right, but there is no real advantage to the defined range assuming that
the lower bound is guint32.

> >- 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.
>

This is a nice feature.

> >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.
>

This seems like the right model to me in terms of making normalization
something done explicitly by the user. The use of the bus metaphor seems
limiting, however. Why not have a complete signal flow graph similar to
the Max family of languages?

Karl

> --p
>

_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| www.peabody.jhu.edu/~karlmac |
-----------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri May 04 2001 - 00:53:06 EEST