W3C home > Mailing lists > Public > public-xg-audio@w3.org > August 2010

Re: Added direct JavaScript processing to WebKit prototype

From: Ted Moallem <ted.moallem@gmail.com>
Date: Sat, 7 Aug 2010 21:07:02 +0530
Message-ID: <AANLkTikrBGwVniUoE6cRra1nhybHpqYVUObd0QgRovkw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:58 UTC