summaryrefslogtreecommitdiffstats
path: root/gst-libs/gst/resample/README
diff options
context:
space:
mode:
authorChristian Schaller <uraeus@gnome.org>2005-05-06 11:41:28 +0000
committerChristian Schaller <uraeus@gnome.org>2005-05-06 11:41:28 +0000
commit086b25d40a8fc3606d70c32af7f6af178e2d804d (patch)
tree2b138bca28d921d8798599f2c745d8014ec631ba /gst-libs/gst/resample/README
parent4cb81e7ecbdc6376e5c676dcffa11758434acd1e (diff)
downloadgst-plugins-bad-086b25d40a8fc3606d70c32af7f6af178e2d804d.tar.gz
gst-plugins-bad-086b25d40a8fc3606d70c32af7f6af178e2d804d.tar.bz2
gst-plugins-bad-086b25d40a8fc3606d70c32af7f6af178e2d804d.zip
remove gst-libs from gst-plugins module as it is in gst-plugins-base now
Original commit message from CVS: remove gst-libs from gst-plugins module as it is in gst-plugins-base now
Diffstat (limited to 'gst-libs/gst/resample/README')
-rw-r--r--gst-libs/gst/resample/README62
1 files changed, 0 insertions, 62 deletions
diff --git a/gst-libs/gst/resample/README b/gst-libs/gst/resample/README
deleted file mode 100644
index f7db1105..00000000
--- a/gst-libs/gst/resample/README
+++ /dev/null
@@ -1,62 +0,0 @@
-
-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...
-