Re: [Linuxsampler-devel] Filter code optimization, sinewave .GIG files request

[<be...@ga...>]

Scrive Christian Schoenebeck <chr...@ep...>:

> 
> Benno, again: the point is not mono / stereo, the point is that the 
> Gigasampler filter always consists of two biquad filters to create the 4 
> filter poles. Maybe with another filter algo there other ways but AFAIK not 
> with biquads. Correct me Steve if I'm telling something incorrect!

sorry :)
the other day when I talked to you I thought 10 coefficients meant
5 for left and 5 for right chan.
But the current code base still does filterleft->apply() and
filterright->apply() so the coeffs are not share yet.
So please don't be too harsh with me :)

> 
> So, a Gigasampler LP filter in LS is actually one biquad BP + one biquad LP,
> a 
> Gigasampler BP in LS are two biquad BPs and a Gigasampler HP is... guess 
> it... yes, a biquad BP + a biquad HP. Means we still need 10 coefficients!

ok, but isn't there a way to make the LPs with only one biquad LP ?
My DSP math is a bit rusty (Steve where are you ? :) ), but if it would
be possible to describe LPs and HPs with only one biquad then I guess
the performance would be bigger (BP would not change I guess since you
always need a LP + HP).

> 
> Anyway, I think we'll stick with the matrix idea and let all (10) filter 
> coefficients be calculated outside the render loop and within the render loop
> 
> we just read those 10 coefficients from the synthesis parameter matrix.

It must be better than the current code anyway 
which places a if(counter % filter_update_interval)
in the innermost loop :)

> 
> I think there will be machines where one approach might be more efficient
> than 
> the other one, so in long term of course the user will be able to choose 
> between e.g. either the matrix or in-loop event solution, preferebly done 
> automatically by some benchmarking routine on his host, controllable by a 
> nice GUI.

I'm curious too about the performance.

On a related note, today I made some benchmarks with and without filter enabled.
without about 150 voices peak, with filter neabled 100-120 voices peak.
Not bad I'd say. (I changed the % filter_update_interval in the if() into &
filter_update_interval) since & is faster than % on most archs.
the update_interval was set to 63 , fragmentsize 128 frames, jackd output.
Athlon 2000 , Maxtor HD 80GB.
I expected much worse performance with the filter enabled and since it's 
already excellent now it can only get better :)
 
This is a piece from Chopin I rendered with the filter enabled.
http://www.linuxsampler.org/misc/chopin1.mp3

more infos at the end of this thread :)
http://www.northernsounds.com/ubbthreads/showflat.php?Cat=&Number=162226&page=0&view=collapsed&sb=5&o=&fpart=1#162226


> 
> CU
> Christian
> 
> P.S. I guess for the not yet implemented so called "turbo low pass" filter of
> 
> Gigasampler, we'll need even 3 biquad filters, means 15 filter coefficients,
> 
> not sure yet

I'd say for now since I assume most sample libs use the standard filters
let make these sound well, the rest is not that important.
Anyway I thought "Turbo" meant less CPU usage thus a simpler equation
in involved while you here seem to imply that the equation for the turbo LP
is more complex.

Another thing we will need to think about is the ability of the voice
to switch on/off the filters to save CPU.
I'm not sure yet what would be the best way to implement it.
Either through virtual C++ classes but while quite efficient (just a jmp asm
instruction more over standard classes) that would probably make it
hard to switch in real time.
C++ function pointers are slower than C funcpointer and I guess it's probably
better not to use them. I'm not sure yet. Only benchmarking can tell us the
truth.
The other alternative is switch() statements, they are translated into
efficient jmp tables but they do not offer the flexibility of func tables.
But I guess for filter on/off switch() is ok.

cheers,
Benno



-------------------------------------------------
This mail sent through http://www.gardena.net