Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: Steve Harris (S.W.Harris@ecs.soton.ac.uk)
Date: Sat Feb 08 2003 - 00:07:41 EET
On Fri, Feb 07, 2003 at 10:04:54 +0100, David Olofson wrote:
> Yeah, that's nasty as well - but not nearly as nasty as forcing
> *outputs* to clamp to the range of whatever inputs you connect them
> to.
Sure.
> > Maybe the host could signal that a control might go out of range
> > and the SDK could do the checking? Thast ways its transdparent to
> > the plugin.
>
> It would require rather a rather high level wrapper for controls,
> meaning you can't just read your values from the event struct.
> *That's* perhaps not much of a problem, but how to implement it?
Yeah, it would still suck.
> if(what?->needs_clamping)
> {
> if(value < what?->clamp_low)
> value = what?->clamp_low;
> else if(value > what?->clamp_high)
> value = what?->clamp_high;
> }
...
> You might ove the conditionals around a bit depending on which case
> you want to be the fastest, but I don't think it gets much more fun
> than that.
The are branchless clamps, which save a few cycles.
> > > 4) Controls have plugin defined hard ranges.
> > > * Either all plugins clamp their inputs, or
> > > hosts snoop all connections.
> > >
> > > 5) Controls have plugin defined soft ranges.
> > > * Plugins that actually have hard ranges
> > > must clamp internally.
> >
> > This is what we have in LADSPA. The hard ranges are not expressed
> > to the host, and they probably dont need to be.
>
> It sounds rather fine to me, but if me *really* don't want plugin code
> to contain explicit clamping, ever, I guess we could figure something
> out... It just seems to me that plugins have a better idea how to
> clamp - and they can quite often use constant limits as well, I
> guess.
I'm fine with this. If the plugin can constrian the inputs itseelf, it
seems reasonable not to have explict host support. We know it works, and
its Simple(TM)
[silence optimisation]
> I do see your point, but I'm not certain whether or not this
> optimization is really useless for normal "one song at a time" use.
> Some real life test data would be really interesting...
You also have to weigh the cost of increased debugging dificulty, and the
erros when lugins mis-estimate thier silence state.
- Steve
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 00:06:40 EET