- From: Ted Moallem <ted.moallem@gmail.com>
- Date: Sat, 7 Aug 2010 21:07:02 +0530
- To: Chris Rogers <crogers@google.com>
- Cc: Chris Marrin <cmarrin@apple.com>, public-xg-audio@w3.org, Corban Brook <corbanbrook@gmail.com>
We are discussing FFT analysis as though it were the one solution for all of our spectral processing needs. The algorithm is convenient when the "overhead" is tolerable, but considering the variety of web-capable platforms out there, the future of web audio might best be served by steering developers toward more efficient signal processing schemes, tailored to task requirements. For example, does 3D spatialization require hundreds of large-sized FFT's per second, or can it be accomplished using low-order Butterworth filters with time-varying coefficients? (If anyone knows the answer, please feel free to chime in.) In any case, rather than considering whether or not javascript can handle the requirements of a modern-day first person shooter game (or peaceful bird-watcher game), I regard javascript audio API as a challenge to work within reasonable constraints where possible, to meet our web audio needs without monopolizing all of a devices resources? [descends from soapbox] -ted On Sat, Aug 7, 2010 at 3:25 AM, Chris Rogers <crogers@google.com> wrote: >> > Very nice. Overhead on my machine is very low (20%) and I think at least >> > half that overhead is WebGL rendering. It would be nice to duplicate the >> > functionality of the Realtime Ananyzer demo so we can understand the >> > difference in overhead between doing FFT's in JS vs native code. >> > >> > ----- >> > ~Chris >> > cmarrin@apple.com >> > >> > Sure, I can do that. I know that the Mozilla folks have already done >> > this and found the JS FFT performance to be acceptable for realtime >> > analysis. Where the FFT overhead gets quite a lot heavier is in >> > panning/spatialization and convolution where there are hundreds of larger >> > sized FFTs per second. >> >> It would be useful to have an apples-to-apples comparison. What sample >> rate does the Realtime Analyzer demo use? It would be nice to do a test of >> 48KHz stereo, just to see how much we can stress it in JS. >> >> ----- >> ~Chris >> cmarrin@apple.com > > It normally runs at 44.1KHz. I think they were getting results like 0.4ms > per size 1024 FFT, which is not very heavy for doing a fairly standard > real-time analysis. When I get some time, I can try to see what results we > get for JSC and V8 in WebKit. I imagine we'll see something similar. > Chris > -- ________________________________ Theodore Moallem moallem@mit.edu 646-872-0283 Sensory Communication Group Research Laboratory of Electronics at MIT Graduate Program in Speech & Hearing Bioscience and Technology Harvard-MIT Division of Health Sciences and Technology -- "My instincts always tend to revolt against helplessness of any kind." -- NK
Received on Monday, 9 August 2010 09:25:31 UTC