gstreamer/gst/audioscale
Andy Wingo 6665c3084c All plugins updated for element state changes.
Original commit message from CVS:
2005-09-02  Andy Wingo  <wingo@pobox.com>

* All plugins updated for element state changes.
2005-09-02 15:43:18 +00:00
..
.gitignore Initial revision 2001-12-22 23:21:55 +00:00
audioscale.vcproj more working plugins 2004-07-27 21:41:30 +00:00
dtof.c configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
dtos.c configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
functable.c configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
gstaudioscale.c All plugins updated for element state changes. 2005-09-02 15:43:18 +00:00
gstaudioscale.h gst/audioscale/gstaudioscale.*: made audioscale resample from any sample rate to any sample rate 2004-08-17 21:27:30 +00:00
Makefile.am make GST_PLUGIN_LDFLAGS only be flags; GST_LIBS should be added manually to each Makefile.am so we are sure it goes 2005-07-13 17:58:07 +00:00
private.h configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
README configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
resample.c configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
resample.h configure.ac: Remove idct and resample libs 2005-04-25 00:23:06 +00:00
test.c configure.ac: Remove idct and resample libs 2005-04-25 00:23: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...