[linux-audio-dev] XAP spec - early scribbles

[torbenh at gmx.de]

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