summaryrefslogtreecommitdiffstats
path: root/gst-libs/gst/resample/README
diff options
context:
space:
mode:
authorThomas Vander Stichele <thomas@apestaart.org>2001-12-23 10:44:28 +0000
committerThomas Vander Stichele <thomas@apestaart.org>2001-12-23 10:44:28 +0000
commit0d4f573fc103544c7972485b010072eda52a0e4b (patch)
treee8345784eb15612c6557e656fca8a108959d0545 /gst-libs/gst/resample/README
parent9161ba1c22b8ac35faf76f34d84f34e16c51ef84 (diff)
downloadgst-plugins-bad-0d4f573fc103544c7972485b010072eda52a0e4b.tar.gz
gst-plugins-bad-0d4f573fc103544c7972485b010072eda52a0e4b.tar.bz2
gst-plugins-bad-0d4f573fc103544c7972485b010072eda52a0e4b.zip
adding resample lib
Original commit message from CVS: adding resample lib
Diffstat (limited to 'gst-libs/gst/resample/README')
-rw-r--r--gst-libs/gst/resample/README62
1 files changed, 62 insertions, 0 deletions
diff --git a/gst-libs/gst/resample/README b/gst-libs/gst/resample/README
new file mode 100644
index 00000000..f7db1105
--- /dev/null
+++ b/gst-libs/gst/resample/README
@@ -0,0 +1,62 @@
+
+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...
+