[LAD] [Faudiostream-devel] Prototyping algorithms and ideas

Fons Adriaensen fons at kokkinizita.net
Thu Jan 31 18:24:25 UTC 2008


Hi Yann,

> Great ! Benvenuti ! If they have programming questions (I am sure pretty 
> they will have some at the beginning ;-)) they are welcome, as well as 
> suggestions and contributions.

I will have some of my own, when I start programming in Faust !

> As I said above I have update the CVS with the revised jack-gtk.cpp 
> architecture file. The faust server is not updated yet, but it will be 
> soon...

Using the _%d does not allow arbitrary port names, so it's not
the most flexible solution, but at least it permits to do what
happened automatically before, if you want it.

> This is a real problem but it should be solved on modern intel cpu by 
> enabling the FTZ mode.

So the generated code should really do that.

> Is fdelay *that* bad or do you have a very demanding application ?

The application is demanding in the sense that it's a psycho-acoustic
experiment - we want to find out if, and in which conditions, the
listener would be able to detect the 'crossover' (which is part of
a larger system). So we must avoid any processing artefacts that
_could_ be suspected to influence the results.

The real problem is not the static FR error, but the modulation
it introduces when the delay is not static. For example, when
it changes by 100 samples per second, the HF part of the signal
is amplitude modulated by 100 Hz. This is much more perceptible
than a constant FR error. A constant bandwidht interpolator with
the same frequency response would probably be acceptable.

> For the  worst cases (x.5 delays)...

For fdelay4(), the worst case is not x.5 but close to x.3. 
It uses the interval [1...2], which is asymmetric. Using
the 'center' [1.5...2.5] would give a discontinuity at x.5
for most inputs.

> BTW, Julius has updated 'filter.lib' to correct one of the
> coefficients of fdelay2 and added Thiran allpass interpolators
> (http://ccrma.stanford.edu/~jos/pasp/Thiran_Allpass_Interpolators.html)
> with very flat frequency response.

Interesting stuff (as usual from JOS), thanks for the pointer.

>> 5. There may be quality issues with some of the libs.
>> The 'bandfilter' for example behaves very strangely.
>>   
> That's right, we should revise it. I must confess that until recently most 
> of our development efforts have been put on the compiler and quite few on 
> the libraries. But with a growing community things are changing...

Also the 'pink noise' in tester has significant power spectrum
errors.

Ciao,

-- 
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.




More information about the Linux-audio-dev mailing list