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

[Steve H. <S.W...@ec...>]

On Sat, Aug 09, 2003 at 07:01:40 +0200, Benno Senoner wrote:
> basically instead of doing (like LADSPA would do)
> 
> am_sample=amplitude_modulator(input_sample,256samples)
> output_sample=LP_filter(am_sample, 256samples)
> 
> (output_sample is a pointer to 256 samples) the current audio block.
> 
> it would be faster do do
> 
> for(i=0;i<256;i++) {
>   output_sample[i]=do_filter(do_amplitude_modulation(input_sample[i]));
> }

Thats not what I did, I did something like:

for(i=0;i<256;i++) {
  do_amplitude_modulation(input_sample+i, &tmp);
  do_filter(&tmp, output_sample[i]);
}

Otherwise your limited in the number of outputs you can have, and this way
makes it more obvious what the execution order is (imagine branches in the
graph) and its no slower.
 
> The question is indeed if yo do LADSPA style processing
> (applying all DSP processing in sequence) the compiler uses SIMD
> and optimization of the processing loops and is therefore faster

I doubt it, I've not come across a compiler that can generate halfway decent
SIMD instructions - including the intel one.

NB you can still use SIMD instruction in blockless code, you just do it
across the input channels, rather than along them.

> But OTOH the blockless processing has the advantage that
> things are not moved around much in the cache.
> The output value of the first module is directly available as the
> input value of the next module without needing to move it to 
> a temporary buffer or variable.

Yes, the only thing we can do is benchmark it.
 
> Ah you are using the concept of duration.
> Ins't it a bit redundant ? Instead of using duration one can use
> duration-less RAMP events and just generate an event that sets 
> the delta ramp value to zero when you want the ramp to stop.

If you just specify the delta 'cos then the receiver is limited to linear
segments, as it cant 2nd guess the duration. This wont work well eg. for
envelopes. Some of the commercial guys (eg. cakewalk) are now evaluating
thier envelope curves every sample anyway, so if we go for ramp events for
envelope curves we will be behind the state of the art. FWIW Adobe use
1/4 audio rate controls, as its convienient for SIMD processing (this came
out in some GMPI discusions).

- Steve