On Sunday 02 March 2003 17.23, [EMAIL PROTECTED] 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 ---
