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

[torbenh at gmx.de]

On Sat, Mar 01, 2003 at 07:52:51PM +0100, David Olofson wrote:
> On Saturday 01 March 2003 15.13, torbenh at gmx.de wrote:
> [...]
> > > Yeah, that makes sense, and I think that's the way most XAP hosts
> > > would do it. I don't like the idea of leaving the insertion of
> > > the (real or implicit) "delay element" in loops to the host, but
> > > that's a host implementation/UI issue entirely. Plugins just
> > > happily chew their audio and events one block at a time.
> >
> > ok... so the host must detect cycles and either warn the user he
> > built something, thats not going to work like he thought or
> > find a smart point where a delay can be inserted.
> 
> ...or ask the user where the delay should be inserted, and then 
> present it as an actual plugin. Then the user could tune the delay. I 
> wouldn't want to leave that to the host configuration, as that can 
> screw your effects up in non-obvious ways. I don't think users should 
> be allowed to do this kind of stuff without at least being informed 
> that it has potential issues. (Who wants their inboxes filled with 
> questions like "Why does it sound funny all of a sudden!?")

ok... host implementation...

> 
> 
> > i am fine with the first only... but this does not change the
> > API... so its irrelevant.
> 
> Right.
> 
> 
> [...silence handling...]
> > lets assume that silence detection is not possible for iir filters.
> > -> iir filter never emits silence.
> >
> > this means we have to call all plugins in "silent" subnets.
> > (at least if we dont have a method for the plugin to tell
> >  the graph traversal we are never silent... but this is out of
> > scope for now)
> 
> Yeah. What's the problem?

we must always call all plugins.
i was thinking that it would be possible to stop processing()
silent subnets.

flagging silence still provides for optimisation IN the plugins.



> 
> BTW, plugins that theoretically never go silent could still have a 
> user controlled silence threshold control...

yes... but this is plugin implementation..

as long as XAP defines a method to describe
silence its ok.

> 
> > a gain set to zero knows it emits silence...
> > and a sample player not playing a sample knows
> > this also...
> >
> > when silence is a flag of an audio buffer at least some
> > plugins could optimize their behaviour and the mixing of
> > n:1 connections would get faster...
> >
> > i dont think it is much hassle
> > remember its not about silence detection its about silence
> > flagging.
> 
> Right.
> 
> 
> > but david is of course right: this does not improve the worst case
> > at all.
> >
> > i think its worth it...
> >
> >
> > just thinking this a little futher:
> >
> > silence with a DC offset :-)
> >
> > d( silence with a DC offset )
> > ----------------------------- = silence
> >         dt
> >
> > int( silence with a DC offset ) = ramp
> >
> > well this leads to symbolic audio processing 8-)
> 
> 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...
> 
> 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.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language