Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: torbenh_AT_gmx.de
Date: Mon Mar 03 2003 - 08:49:09 EET
On Mon, Mar 03, 2003 at 09:57:50AM +0100, David Olofson wrote:
> On Sunday 02 March 2003 17.23, torbenh_AT_gmx.de wrote:
> [...silence handling...]
> > > Yeah. What's the problem?
> >
> > we must always call all plugins.
> > i was thinking that it would be possible to stop processing()
> > silent subnets.
>
> Well, it's just that if you stop calling process(), something else
> will have to be done to decide when to start calling it again... I
> suspect that that will cost significantly more than a function call
> if the feature is going to be seriously usable. If a plugin does the
> testing itself, there's no limit to what it can check for, and the
> checking code can still be highly optimized.
yes... we agree on that..
>
>
> > flagging silence still provides for optimisation IN the plugins.
>
> Yes.
>
>
> > > BTW, plugins that theoretically never go silent could still have
> > > a user controlled silence threshold control...
> >
> > yes... but this is plugin implementation..
>
> Yes, although it might make sense to have a standard
> "SILENCE_THRESHOLD" control, so hosts can present it as a central
> control for the whole net, or for a group of plugins (mixer inserts,
> fo example), or whatever. Where it's not present, the host will
> assume that the plugin consideres only absolute silence, provided the
> plugin supports silence at all.
ok ... so we are going one level up now...
standard names for controls...
>
>
> > as long as XAP defines a method to describe
> > silence its ok.
>
> Right. We just have to make sure the supporting features are there as
> well, or silence processing will just end up as some obscure and hard
> to use feature that will be a major PITA for any user who need to use
> it. Hosts must have enough information to be able to figure it out
> for themselves, without the user messing with each plugin manually.
how will the silence be indicated ?
NULL is not so good for inplace processing :)
is there inplace processing in XAP ?
>
>
> [...]
> > > Silence with a DC offset is not silence, IMO. Unless you're going
> > > to stay on that level *forever*, it's not DC, and then it can't
> > > be silence by any definition, can it?
> >
> > no... its "silence with a dc offset" != "silence" . effectively
> > making it a constant for this next block...
>
> Yeah, I can see where you're going, but is it useful to assume that
> silent buffers are equivalent to zeroes?
>
> A plugin that's optimized for silent input is not just a matter of an
> alternative loop that takes hardcoded zeroes (or a fixed DC level)
> instead of real data. That would hardly affect performance at all
> with most algorithms. The real gain is when the tail is out and you
> can stop processing completely, only generating "silent" flagged
> buffers. This *can* indeed happen if the inputs stay at fixed DC
> levels for extended periods of time - but how likely is that?
a fixed DC of 1000 means something completely different to a
frequency modulator than silence...
but silence is only dcsilence(0)
>
> (At least in XAP, we don't use audio inputs for control data. We use
> sample accurate timestamped events with linear ramping.)
a frequency modulator takes audio input as i see it.
even if linear ramping would be extended to polynoms
and other nonlinear things it would never have the power
of an audio rate control...
>
>
> > > Either way, remember that we're dealing with blocks here. (Larger
> > > time spans are pretty irrelevant from a practical POV.) If any DC
> > > level is silence, is a square wave that happens to have a period
> > > of exactly two blocks silence as well? ;-)
> >
> > no.
> > example:
> > block size = square_period / 2
> >
> > square_phase = 0
> >
> > block 1 = dcsilence(1)
> > block 2 = dcsilence(-1)
> > ...
> >
> > silence flaggin means this block only contains zeros.
> > dcsilence(x) flagging means this block only contains x
> >
> > this is like having metadata on an audio block
> > providing smart plugins with the capability to optimize their
> > processing.
>
> Yeah, I understand that, but I don't see how plugins that use any
> significant amount of cycles can make use of this. "Register instead
> of stream" kind of optimizations are pretty much irrelevant for most
> plugins, I think, and all the special cases it would require (one
> case for every likely combination of active, silent or DC inputs) are
> just not worth it.
i guess you are right... but if you think this somewhat further it
is a nice idea... making up a different very complex protocol
it should be handled like extended ramping events...
-- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
This archive was generated by hypermail 2b28 : Mon Mar 03 2003 - 12:24:24 EET