W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: fftSize requirement for RealtimeAnalyserNode

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Fri, 23 Mar 2012 01:36:09 +0200
Message-ID: <CAJhzemXY0Bd69diOj-4MZ4mdDdP6pz9MpSTHm97J604MgoevDA@mail.gmail.com>
To: Raymond Toy <rtoy@google.com>
Cc: "Wei, James" <james.wei@intel.com>, "public-audio@w3.org" <public-audio@w3.org>
On Thu, Mar 22, 2012 at 11:27 PM, Raymond Toy <rtoy@google.com> wrote:

> On Thu, Mar 22, 2012 at 4:07 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>> I hadn't actually even noticed this. Interesting. Why exactly should the
>> value be a power of two? It seems to me like the spec shouldn't say
>> something like this. Sure, power of two FFTs are easier to implement than
>> others, but IIRC they are rarely the fastest. And if we aim for
>> performance, the implementation should probably be using something like
>> FFTW that allows for any buffer size anyway.
> My recollection is that the power of two FFT is faster (possibly using
> radix-4 and radix-8 implementations internally).

Yeah, you want small prime factors. but it is only relevant for very large
FFT:s, but it is O(n log n) in all cases so it still scales pretty well for
large sizes.

> Do you have a specific need for a non-power of two analysis?  I'm just
> curious.

It just seems like an arbitrary limit. Most of the time, you probably want
to set the length in seconds, not samples, and then you won't get a

> Also, FFTW uses the GPL license, so if the browser is also not GPL, there
> are potential legal issues.  This is where you go ask a lawyer.

There are other ones as well (kissfft is BSD 3-clause for example, IIRC),
but I don't think the licensing of certain FFT implementations is a valid
argument to base the spec on.

Also, the algorithm isn't complex, you could implement it without a library.

Received on Thursday, 22 March 2012 23:36:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:58 UTC