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

Re: Added direct JavaScript processing to WebKit prototype

From: Chris Rogers <crogers@google.com>
Date: Fri, 6 Aug 2010 14:55:12 -0700
Message-ID: <AANLkTinAqOMKdb_h1mn95djBt1FJD7fuTfb=OScof_fB@mail.gmail.com>
To: Chris Marrin <cmarrin@apple.com>
Cc: public-xg-audio@w3.org, Corban Brook <corbanbrook@gmail.com>
> > 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.

Received on Friday, 6 August 2010 21:55:43 UTC

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