diff options
Diffstat (limited to 'media/kiss_fft/README')
| -rw-r--r-- | media/kiss_fft/README | 51 |
1 files changed, 12 insertions, 39 deletions
diff --git a/media/kiss_fft/README b/media/kiss_fft/README index 03b2e7a9c1..b18d62a020 100644 --- a/media/kiss_fft/README +++ b/media/kiss_fft/README @@ -44,30 +44,6 @@ The core fft and most tools/ code can be compiled to use float, double, Q15 short or Q31 samples. The default is float. -BACKGROUND: - - I started coding this because I couldn't find a fixed point FFT that didn't -use assembly code. I started with floating point numbers so I could get the -theory straight before working on fixed point issues. In the end, I had a -little bit of code that could be recompiled easily to do ffts with short, float -or double (other types should be easy too). - - Once I got my FFT working, I was curious about the speed compared to -a well respected and highly optimized fft library. I don't want to criticize -this great library, so let's call it FFT_BRANDX. -During this process, I learned: - - 1. FFT_BRANDX has more than 100K lines of code. The core of kiss_fft is about 500 lines (cpx 1-d). - 2. It took me an embarrassingly long time to get FFT_BRANDX working. - 3. A simple program using FFT_BRANDX is 522KB. A similar program using kiss_fft is 18KB (without optimizing for size). - 4. FFT_BRANDX is roughly twice as fast as KISS FFT in default mode. - - It is wonderful that free, highly optimized libraries like FFT_BRANDX exist. -But such libraries carry a huge burden of complexity necessary to extract every -last bit of performance. - - Sometimes simpler is better, even if it's not better. - FREQUENTLY ASKED QUESTIONS: Q: Can I use kissfft in a project with a ___ license? A: Yes. See LICENSE below. @@ -78,10 +54,6 @@ FREQUENTLY ASKED QUESTIONS: 2) mixed build environment -- all code must be compiled with same preprocessor definitions for FIXED_POINT and kiss_fft_scalar - Q: Will you write/debug my code for me? - A: Probably not unless you pay me. I am happy to answer pointed and topical questions, but - I may refer you to a book, a forum, or some other resource. - PERFORMANCE: (on Athlon XP 2100+, with gcc 2.96, float data type) @@ -111,24 +83,25 @@ UNDER THE HOOD: FFTs in parallel (packed into real&imag), and then combines them via twiddling. The result is nfft/2+1 complex frequency bins from DC to Nyquist. If you don't know what this means, search the web. - The fast convolution filtering uses the overlap-scrap method, slightly - modified to put the scrap at the tail. + The fast convolution filtering uses the overlap-scrap method, slightly modified to put + the scrap at the tail. LICENSE: - Revised BSD License, see COPYING for verbiage. + BSD-3-Clause License, see LICENSE for verbiage. Basically, "free to use&change, give credit where due, no guarantees" Note this license is compatible with GPL at one end of the spectrum and closed, commercial software at the other end. See http://www.fsf.org/licensing/licenses - - A commercial license is available which removes the requirement for attribution. Contact me for details. - - -TODO: + + This fork of the library always requires attribution. Contrary to the original version of the library, + written by a sole developer, no exception to the license is available that allows use without attribution + because of contributed code. + +TO-DO: *) Add real optimization for odd length FFTs *) Document/revisit the input/output fft scaling *) Make doc describing the overlap (tail) scrap fast convolution filtering in kiss_fastfir.c *) Test all the ./tools/ code with fixed point (kiss_fastfir.c doesn't work, maybe others) -AUTHOR: - Mark Borgerding - Mark@Borgerding.net +AUTHORS: + Mark Borgerding (mark@borgerding.net) + Mark Straver BASc (moonchild@palemoon.org) |