W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Simplifying specing/testing/implementation work

From: Marcus Geelnard <mage@opera.com>
Date: Thu, 19 Jul 2012 14:36:15 +0200
To: "Jussi Kalliokoski" <jussi.kalliokoski@gmail.com>
Cc: public-audio@w3.org
Message-ID: <op.who1aprfm77heq@mage-desktop>
Den 2012-07-19 14:07:06 skrev Jussi Kalliokoski  
<jussi.kalliokoski@gmail.com>:

> This! +9999. Exactly what I've been wanting all along.

:)


> My colleague Jens Nockert is working on something called Hydrazine, which
> is a JS extension that provides an API that takes advantage of SIMD
> instructions and friends, giving typed arrays a sort of a high-level
> assembly language to manipulate them efficiently.

Very interesting! Sounds a bit like what GLSL is to graphics processing  
(as a side note: wise from the history of graphics processing, I'd say  
that what the Audio API really neads is a "shader" language for arbitrary  
audio processing - it just so happens that that language is JavaScript).

> Although, provided we had a high-performance FFT library (on the other
> hand it's actually really surprising how fast an FFT you can write in JS)
> and eventually better ways to do parallel processing
> in JS, plus what Hydrazine aims to do, the performance difference of a
> convolution engine written in JS vs native would be insignificant.

Yes, based on my benchmarking I'd say that JS is about a factor 5x - 10x  
away from highly optimized native SIMD code today (for typical 1D  
processing), and from what I can tell there's really nothing stopping JS  
 from coming very close to 1x within a few years from now.

However, if JS was "fast enough" today, we probably wouldn't have the  
specialized AudioNodes to begin with. The point of exposing a few  
primitive DSP functions is mostly to bridge the gap between "now" and "the  
future".

> I think IIR filters are unnecessary to be provided by the API,
> I hardly think they have similar performance differences / problems as  
> FFT
> and Convolution, which I think are the things the API should provide.

Actually even the simplest of all operations, addition, is over 10x faster  
in native SIMD code than the fastest JS engine, so I'd say that the  
performance difference is definitely there. On the other hand, it might  
not be as much of a bottle neck as an FFT (at least not for low order  
filters). Also, the IIR filter is really a more general version of  
convolution.

> Agree with the fact that JSAudioNode needs to be renamed. What about
> something like CustomAudioNode or ProgrammableAudioNode?

+1 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17348)

> Also, I'd like to add MediaElementAudioSource (this name I think needs
> simplifying as well) to the list of core elements.

True! After all, it's the de facto audio standard today, so no need to  
exclude it.

Regards,

   Marcus


-- 
Marcus Geelnard
Core Graphics Developer
Opera Software ASA
Received on Thursday, 19 July 2012 12:36:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 12:36:43 GMT