[linux-audio-dev] Blockless processing

Simon Jenkins sjenkins at blueyonder.co.uk
Fri Dec 13 17:04:01 UTC 2002


  John Lazzaro wrote:

>>Steve Harris <S.W.Harris at ecs.soton.ac.uk> writes:
>>
>>SAOL is still block based AFAIK. 
>>    
>>
>See:
>
>http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf
>
>Sfront does no block-based optimizations. And for many
>purposes, sfront is fast enough to do the job. 
>
>It may very well be that sfront could go even faster
>with blocking, although the analysis is quite subtle --
>in a machine with a large cache, and a moderate-sized
>SAOL program, you're running your code and your data 
>in the cache most of the time.           
>
I totally agree that there's no intrinsic performance difference
between blockless and block-based processing other than what sits
better in the cache, and that block-based processing might very
well go faster because of this, although it might not.

But the plugin scheme we've been discussing under the title of
"blockless processing" raises a few more issues.

By doing just-in-time compilation of a whole bunch of connected
plugins, which may have been written separately but are now
to be connected together into a graph by the host application,
you get the following opportunities:

+ Code optimisation across plugin boundaries (especially powerful
if there are unconnected inputs and outputs, or constant control
values).

+ Compile-time parameterisation of plugins (ok, you can do that
with any plugin but "compile time" is actually instantiation time
in this scheme so it becomes something the host can specify).

+ One-sample latency between connected plugins (the original
reason this whole thing got discussed IIRC).

The compiled result might well be partially or fully block processed
- subject to the host tolerating that, and internal feedback loops being
processed sample-by-sample - but the compiler would be able to base
its optimisation decisions on how the *entire* graph to be processed
fitted into the *actual* available cache.

Simon Jenkins
(Bristol, UK)





More information about the Linux-audio-dev mailing list