mirror of
https://github.com/mborgerding/kissfft.git
synced 2025-05-27 21:20:27 -04:00
Update README.md
This commit is contained in:
lucifetsmith
GitHub
parent
6668a8214b
commit
5ba824ceec
79
README.md
79
README.md
@ -2,20 +2,18 @@
|
||||
|
||||
KISS FFT - A mixed-radix Fast Fourier Transform based up on the principle,
|
||||
"Keep It Simple, Stupid."
|
||||
|
||||
There are many great fft libraries already around. Kiss FFT is not trying
|
||||
to be better than any of them. It only attempts to be a reasonably efficient,
|
||||
moderately useful FFT that can use fixed or floating data types and can be
|
||||
incorporated into someone's C program in a few minutes with trivial licensing.
|
||||
|
||||
USAGE:
|
||||
## USAGE:
|
||||
|
||||
The basic usage for 1-d complex FFT is:
|
||||
|
||||
```c
|
||||
#include "kiss_fft.h"
|
||||
|
||||
kiss_fft_cfg cfg = kiss_fft_alloc( nfft ,is_inverse_fft ,0,0 );
|
||||
|
||||
while ...
|
||||
|
||||
... // put kth sample in cx_in[k].r and cx_in[k].i
|
||||
@ -25,8 +23,8 @@ USAGE:
|
||||
... // transformed. DC is in cx_out[0].r and cx_out[0].i
|
||||
|
||||
kiss_fft_free(cfg);
|
||||
|
||||
Note: frequency-domain data is stored from dc up to 2pi.
|
||||
```
|
||||
- **Note**: frequency-domain data is stored from dc up to 2pi.
|
||||
so cx_out[0] is the dc bin of the FFT
|
||||
and cx_out[nfft/2] is the Nyquist bin (if exists)
|
||||
|
||||
@ -36,17 +34,17 @@ functions you'll need to use.
|
||||
Code definitions for 1d complex FFTs are in kiss_fft.c.
|
||||
|
||||
You can do other cool stuff with the extras you'll find in tools/
|
||||
|
||||
* multi-dimensional FFTs
|
||||
* real-optimized FFTs (returns the positive half-spectrum: (nfft/2+1) complex frequency bins)
|
||||
* fast convolution FIR filtering (not available for fixed point)
|
||||
* spectrum image creation
|
||||
> - multi-dimensional FFTs
|
||||
> - real-optimized FFTs (returns the positive half-spectrum:
|
||||
(nfft/2+1) complex frequency bins)
|
||||
> - fast convolution FIR filtering (not available for fixed point)
|
||||
> - spectrum image creation
|
||||
|
||||
The core fft and most tools/ code can be compiled to use float, double,
|
||||
Q15 short or Q31 samples. The default is float.
|
||||
|
||||
|
||||
BACKGROUND:
|
||||
## 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
|
||||
@ -59,45 +57,44 @@ 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.
|
||||
> 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.
|
||||
**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.
|
||||
## FREQUENTLY ASKED QUESTIONS:
|
||||
> Q: Can I use kissfft in a project with a ___ license?
|
||||
> A: Yes. See LICENSE below.
|
||||
|
||||
Q: Why don't I get the output I expect?
|
||||
A: The two most common causes of this are
|
||||
1) scaling : is there a constant multiplier between what you got and what you want?
|
||||
2) mixed build environment -- all code must be compiled with same preprocessor
|
||||
definitions for FIXED_POINT and kiss_fft_scalar
|
||||
>Q: Why don't I get the output I expect?
|
||||
> A: The two most common causes of this are
|
||||
> 1) scaling : is there a constant multiplier between what you got and what you want?
|
||||
> 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.
|
||||
> 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:
|
||||
## PERFORMANCE
|
||||
(on Athlon XP 2100+, with gcc 2.96, float data type)
|
||||
|
||||
Kiss performed 10000 1024-pt cpx ffts in .63 s of cpu time.
|
||||
For comparison, it took md5sum twice as long to process the same amount of data.
|
||||
|
||||
Transforming 5 minutes of CD quality audio takes less than a second (nfft=1024).
|
||||
|
||||
DO NOT:
|
||||
... use Kiss if you need the Fastest Fourier Transform in the World
|
||||
... ask me to add features that will bloat the code
|
||||
**DO NOT:**
|
||||
- use Kiss if you need the Fastest Fourier Transform in the World
|
||||
- ask me to add features that will bloat the code
|
||||
|
||||
UNDER THE HOOD:
|
||||
## UNDER THE HOOD
|
||||
|
||||
Kiss FFT uses a time decimation, mixed-radix, out-of-place FFT. If you give it an input buffer
|
||||
and output buffer that are the same, a temporary buffer will be created to hold the data.
|
||||
@ -116,18 +113,18 @@ UNDER THE HOOD:
|
||||
The fast convolution filtering uses the overlap-scrap method, slightly
|
||||
modified to put the scrap at the tail.
|
||||
|
||||
LICENSE:
|
||||
## LICENSE
|
||||
Revised BSD License, see COPYING 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
|
||||
|
||||
TODO:
|
||||
*) 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)
|
||||
## TODO
|
||||
- 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:
|
||||
## AUTHOR
|
||||
Mark Borgerding
|
||||
Mark@Borgerding.net
|
||||
|
||||
Loading…
Reference in New Issue
Block a user