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

David Olofson david at olofson.net
Sat Mar 1 14:02:07 UTC 2003


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!?")


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

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


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

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? ;-)


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




More information about the Linux-audio-dev mailing list