Re: [Linuxsampler-devel] sample accurate events and scheduling events in the future

[Simon J. <sje...@bl...>]

  David Olofson wrote:

>>[Benno:]Now if we assume we do all blockless processing eg the
>>dsp compiler generates one giant equation for each dsp network
>>(instrument). output = func(input1,input2,....)
>>
>>Not sure we gain in performance compared to the block based
>>processing where we apply all operations sequentially on a buffer
>>(filters, envelopes etc) like they were ladspa modules but without
>>calling external modules but instead "pasting" their sources in
>>sequence without function calls etc.
>>    
>>
>
>I suspect it is *always* a performance loss, except in a few special 
>cases and/or with very small nets and a good optimizing "compiler".
>
You certainly need an optimising compiler because the gains, if present,
would be achieved by register optimisations. I was getting better 
performance
from the paste-together-one-big-function approach and had thought that it
"just was" better (provided the function fit in the cache of course), 
but there's
been some disagreement on the matter so I'm going over it again.

>Audio rate controls *are* the real answer (except for some special 
>cases, perhaps; audio rate text messages, anyone? ;-), but it's still 
>a bit on the expensive side on current hardware. (Filters have to 
>recalculate coefficients, or at least check the input, every sample 
>frame, for example.)
>
Agreed it may be very expensive to send a-rate control to certain inputs
of certain modules. OTOH that's a limitation of those particular inputs,
on those particular modules. Given that we're going to downcompile it
would maybe be possible to deal with such inputs "surgically" by (for
example) generating code which k-rated connections to just those inputs.

Simon Jenkins
(Bristol, UK)