[linux-audio-dev] Blockless processing

[Simon Jenkins]

Steve Harris wrote:

>I couldn't resist it so I hacked up a quick script to try the blockless,
>dynamicly compiled processing we were discussing the other day.
>
>http://plugin.org.uk/blockless/
>
Nice! I've only had a very quick look so far, but just knowing it exists has
improved my day by quite a bit.

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

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.

Anyway I know this sort of thing can cause problems occasionally
because I've suffered them: If you try to do anything too tricky with the
logic modules in the Nord Modular you can end up "latching" a logic
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).

>I used the biquad in a simple toplevel graph
>(http://plugin.org.uk/blockless/blockless/graphs/test4.g), it takes about
>50 cycles per sample on PIII (interestingly its compiles to slightly worse
>code in gcc3.2), the source my script produces is very tangled and
>funtion-y, but gcc manages to untagle it and inline it all, eg.
>http://plugin.org.uk/blockless/blockless/intem/test4.c
>
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.

This would need a recompile every time a connection is made (which is
already the case in your implementation anyway) rather than just when an
atom is added or removed though.

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.

Simon Jenkins
(Bristol, UK)