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

[David Olofson]

On Friday 28 February 2003 22.01, Dave Griffiths wrote:
> On Fri, 28 Feb 2003 19:05:19 +0100
>
> David Olofson <david at olofson.net> wrote:
> > On Friday 28 February 2003 09.20, torbenh at gmx.de wrote:
> > [...]
> >
> > > random latency ? how do you mean that ?
> >
> > Latency depends on how you happen to construct the net (order of
> > instantiation, connections etc) and/or the actual layout of the
> > net, in "non-obvious" ways.
>
> In ssm I sort the network each time a connection is made/destroyed,
> and generate a ordered list of modules to process from the root up
> to the leaves. It has to cope with circular sections, which
> unavoidably introduce latency, but it works. It also automatically
> means unconnected modules don't get processed, which is nice.

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.


> > > see current implementation...
> >
> > [...]
> >
> > > one advantage is with silent sub nets....
> >
> > I'm not sure it's that easy. What about plugins with tails and/or
> > internal state? (Delay, reverbs, most filters, ...) You can't
> > just stopp running these when they get no input, or when you
> > don't need their output.
>
> I must admit I haven't followed this discussion too closely, so
> you've probably covered all this before, but I think all this work
> to figure out if you are processing silent data is not really as
> much a win to be worth the hassle - as it won't ever make the worst
> case faster.

There isn't much work at all, really. Still, it's complexity, and it 
has to be motivated. IMNSHO, determinism is *not* a valid reason to 
avoid silence support, but handling large nets where only part of the 
net will run at any time, and using the leftover CPU time for other 
stuff (GUI, for example) are two reasons to have it. I don't think 
we've decided anything, so I guess it all depends on whether or not 
it can be prooven useful enough to motivate it's existence.


> Time would probably be better spent finding actual bottlenecks and
> optimising them.

Yes, but only in systems where you actually *hit* the theoretical 
worst case, and where you have no use for any "low quality" leftover 
CPU time. I think this means that your average DAW can benefit from 
silence processing, but so far, I've seen no real proof for or 
against. (What's "your average DAW", for starters? How many users 
must benefit for the feature to be warranted...?)


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