Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: torbenh_AT_gmx.de
Date: Sun Mar 02 2003 - 18:23:08 EET
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
This archive was generated by hypermail 2b28 : Sun Mar 02 2003 - 21:55:08 EET