Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: David Olofson (david_AT_olofson.net)
Date: Mon Mar 03 2003 - 10:57:50 EET
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 ---
This archive was generated by hypermail 2b28 : Mon Mar 03 2003 - 10:57:03 EET