[linux-audio-dev] Blockless processing

Steve Harris S.W.Harris at ecs.soton.ac.uk
Fri Dec 13 05:25:01 UTC 2002


On Fri, Dec 13, 2002 at 02:50:52AM +0000, Simon Jenkins wrote:
> >I went as far as defining a biquad filter in the graph format
> >(http://plugin.org.uk/blockless/blockless/modules/biquad.g), but it
> >dosen't quite work because the execution order is more or less random.
> >
> I haven't looked closely yet but do you mean that the atoms are being
> executed in some compiler-determined order that doesn't reflect the flow
> of data through the graph?

Its just programmer lazyness, the modules are resolved in an order
determined by a hashtable they get stored in.
 
> Someone suggested here that single sample latencies, eg in feedback loops,
> shouldn't cause noticeable problems. (There's got to be one somewhere
> in a feedback loop anyway). The combined effect of whole load of atoms
> executing in the wrong order might be a different matter though.

Yes, especially in a biquad.
 
> value that hasn't been evaluated yet. (OTOH the Modular is a synth not
> an FPGA and I was well across the line which divides use from abuse
> before I even noticed that I wasn't in control of the evaluation order).

You can control it, its goverened by the order you place the modules in
the patch. I managed to build an AD converter that way, but it was damn
hard work.
 
> The optimisations I'm really hoping to see are for the compiler to strip out
> dead code when an output isn't connected, and to propogate a constant 0
> through the graph when an input isn't connected.

Well that happens, the constant 0.0 gets propagated, because I manually
set it in the source :)
 
> Thinking again about what the Nord Modular does: You can make and break
> connections between existing modules as much as you like with neither a
> glitch nor a change in (what it claims to be its) CPU usage. As soon as you
> add a new module, though, all the existing modules reset themselves and
> everything "starts again" with the new module, suggesting that the existing
> modules have all lost their contexts. This is *really* annoying if 
> you're trying
> to develop a patch or sequence that evolves very slowly.

Yes, It might be possible to replicate this by use of exteme binary
mangling, but its not somewhere I want to go.

I just did this to see what would happen, if someone were going to take a
more serious stab at it they would have to take account of these issues.

- Steve



More information about the Linux-audio-dev mailing list