Two speed IIR (notably for debug timing)

[Roquen]

Debugging timing information is frequently hard to read.  This is far from the best method, but tends to spew out more readable results than raw data.  Of course usage isn't limited to filtering timing information.

This example snippet implements a two-speed adaptive IIR (infinite impulse response filter).  A base IIR simply lerps the current input toward current filtered value with a constant lerp constant.  The 'heavier' the filter, the slow the output adapts to the input.  Here we have a version with two compile time constant speed which are selected by the percent difference between the current filter and actual.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24

// constant to determine the choice between the two speeds  private static final float FILTER_P = 0.1f;  // current: if filtered is within 10% of current then use slow     // constant for slow speed adaption  private static final float FILTER_S = 0x1p-6f;     // constant for fast speed adaption  private static final float FILTER_F = 0x1p-2f;  // current: 75% filtered, 25%     /**    * 2-speed adaptive IIR.    */   public static float twospeedIIR(float filtered, float current)   {     // difference between the current filtered and actual values    float diff = Math.abs(filtered-current);           // choose between the two speeds    if (diff < FILTER_P*filtered)       return (1-FILTER_S)*filtered + FILTER_S*current;         return(1-FILTER_F)*filtered + FILTER_F*current;   }

[Best Username Ever]

Where do the constants come from? What is the 0x1p- syntax?

[Roquen]

The constants (in this case) came straight out of my butt.  I'll tweak them depending on what I'm timing.  The 0x.. syntax is floating point in hex form...so you specify an exact value (not so in decimal and decimal-to-binary conversion is tricky, error prone, etc.)

some examples here: http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#toHexString%28double%29

Games published by our own members! Check 'em out!

[nsigma]

Interesting!  Am I right in presuming you're using this to smooth timing values from a single source, rather than smooth out differences between two clock sources?  I ported code from libtimefilter to Java to use to correct jitter between the soundcard and system clocks in the JAudioLibs code (here).  Not sure if the same delay-locked loop principle could be used here, or how similar it is to what you're doing?

More info about it here too - kokkinizita.linuxaudio.org/papers/usingdll.pdf

[Roquen]

Yeap, single source.  This is just about as dumb as low-pass filters get.  And sure you could use a less dumb filter to do the same thing.  Somewhere I have a fully adaptive version (speed varies continuously) that takes all kinds of set-up parameters:  like the frequency you what to read the output and frequency new input is coming is...yada, yada.  I find using this easier though.