Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: David Olofson (david_AT_olofson.net)
Date: Sat Mar 01 2003 - 01:29:10 EET
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 ---
This archive was generated by hypermail 2b28 : Sat Mar 01 2003 - 01:24:18 EET