gstreamer/gst-libs/gst/resample
Andy Wingo 0cc78c5ef8 added plugin_desc structures to libs, which makes their locations cached in the registry. this speeds plugin loading ...
Original commit message from CVS:
* added plugin_desc structures to libs, which makes their locations cached in the registry. this
speeds plugin loading considerably, especially on uninstalled versions.

* put the lib path before all others, for speed reasons.

* some fixes to adder's caps.

* added linefeeds (\n) to GST_DEBUG strings to match GST_INFO behavior. this is more sane. all
code will need to be converted. i think some perl can do this.
2002-03-24 20:55:44 +00:00
..
dtos.c removal of //-style comments don't link plugins to core libs -- the versioning is done internally to the plugins with... 2002-03-19 04:10:06 +00:00
functable.c removal of //-style comments don't link plugins to core libs -- the versioning is done internally to the plugins with... 2002-03-19 04:10:06 +00:00
Makefile.am removal of //-style comments don't link plugins to core libs -- the versioning is done internally to the plugins with... 2002-03-19 04:10:06 +00:00
README adding resample lib 2001-12-23 10:44:28 +00:00
resample.c added plugin_desc structures to libs, which makes their locations cached in the registry. this speeds plugin loading ... 2002-03-24 20:55:44 +00:00
resample.h adding resample lib 2001-12-23 10:44:28 +00:00
test.c removal of //-style comments don't link plugins to core libs -- the versioning is done internally to the plugins with... 2002-03-19 04:10:06 +00:00

This is a snapshot of my current work developing an audio
resampling library.  While working on this library, I started
writing lots of general purpose functions that should really
be part of a larger library.  Rather than have a constantly
changing library, and since the current code is capable, I
decided to freeze this codebase for use with gstreamer, and
move active development of the code elsewhere.

The algorithm used is based on Shannon's theorem, which says
that you can recreate an input signal from equidistant samples
using a sin(x)/x filter; thus, you can create new samples from
the regenerated input signal.  Since sin(x)/x is expensive to
evaluate, an interpolated lookup table is used.  Also, a
windowing function (1-x^2)^2 is used, which aids the convergence
of sin(x)/x for lower frequencies at the expense of higher.

There is one tunable parameter, which is the filter length.
Longer filter lengths are obviously slower, but more accurate.
There's not much reason to use a filter length longer than 64,
since other approximations start to dominate.  Filter lengths
as short as 8 are audially acceptable, but should not be
considered for serious work.

Performance:  A PowerPC G4 at 400 Mhz can resample 2 audio
channels at almost 10x speed with a filter length of 64, without
using Altivec extensions.  (My goal was 10x speed, which I almost
reached.  Maybe later.)

Limitations: Currently only supports streams in the form of
interleaved signed 16-bit samples.

The test.c program is a simple regression test.  It creates a
test input pattern (1 sec at 48 khz) that is a frequency ramp
from 0 to 24000 hz, and then converts it to 44100 hz using a
filter length of 64.  It then compares the result to the same
pattern generated at 44100 hz, and outputs the result to the
file "out".

A graph of the correct output should have field 2 and field 4
almost equal (plus/minus 1) up to about sample 40000 (which
corresponds to 20 khz), and then field 2 should be close to 0
above that.  Running the test program will print to stdout
something like the following:

  time 0.112526
  average error 10k=0.4105 22k=639.34

The average error is RMS error over the range [0-10khz] and
[0-22khz], and is expressed in sample values, for an input
amplitude of 16000.  Note that RMS errors below 1.0 can't
really be compared, but basically this shows that below
10 khz, the resampler is nearly perfect.  Most of the error
is concentrated above 20 khz.

If the average error is significantly larger after modifying
the code, it's probably not good.



dave...