[whatwg] Codecs for <audio> and <video>
Boris Zbarsky
bzbarsky at MIT.EDU
Sat Aug 8 20:18:36 PDT 2009
Chris McCormick wrote:
> It's a bit of an open ended how-long-is-a-piece-of-string sort of a question in
> that you will generally make synthesizers which require less CPU than what your
> computer is able to provide, for the obvious reason that they won't work
> otherwise. So the real answer is that you want the DSP system to go absolutely
> as fast as possible I guess, so that you can squeeze as much synthesis out as
> possible.
OK, sure. But you indicated that ECMAScript would be unacceptable for
the use cases, period....
> So you could do some
> simple synthesis with pure Javascript if it was able to loop through say 100
> arrays of 4410 samples each, doing vector operations on those arrays, in under
> 100ms.
See attached HTML file. It creates 103 arrays of length 4410, then goes
through them starting with array #4 and sets array n to the product of
arrays n-1 and n-2 plus array n-3.
If I initialize the arrays with random 16-bit integers, the numbers I
see are like so (on a year-old laptop):
Gecko (build that is pretty close to Firefox 3.6a1):
Setup: 96ms
Vector ops: 43ms
Webkit nightly (in Safari, so using SFX):
Setup: 170ms
Vector ops: 41ms
I don't have a Chrome build around to test how well V8 would do on this
testcase, and Opera 10 beta is giving me numbers about 20x slower than
the above. Firefox 3 gives numbers about 5x slower than the above. I
can't test IE over here easily (it's a Mac laptop), but I would expect
it to be somewhat slower than the above numbers too.
So I can certainly see how you would feel that ECMAScript is not fast
enough for this sort of thing: until recently it wasn't, for the most
part. But at this point it seems to be ok, if not great (I have about
2x headroom for your target numbers for simple sound synthesis over
here; someone with an older computer would have less, and more
complicated operations might take more time). And I can tell that at
least in Gecko's case there's ongoing work to make array access faster...
So it seems fairly likely to me that all UAs will end up with ECMAScript
implementations fast enough to do what you want here sooner than all UAs
would implement a brand-new set of functionality. Certainly that's the
case for Safari and Gecko-based browsers. :)
-Boris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090808/a513db3c/attachment-0002.html>
More information about the whatwg
mailing list