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

[David Olofson]

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.


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


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


[...]
> > 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?

(At least in XAP, we don't use audio inputs for control data. We use 
sample accurate timestamped events with linear ramping.)


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


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---