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

Re: Simplifying specing/testing/implementation work

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Thu, 19 Jul 2012 17:11:38 +0300
Message-ID: <CAJhzemUaaqLFChA7iuvfRr8L-MDwj4U7dudyru6t5NK-LnwiWw@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: public-audio@w3.org
On Thu, Jul 19, 2012 at 3:36 PM, Marcus Geelnard <mage@opera.com> wrote:

> 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).

I've been thinking about the same a lot as well. Given that we provide
these proper primitives to JavaScript, it should be a relatively good
compilation target for more application-specific languages, such as an
audio shader language.

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".

Yes, that's what I was saying as well. I just don't think we should make
more than necessary, i.e. cover the biggest bottlenecks.

>  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.

Obviously SIMD code is faster than addition in JS now, for example. And
yes, IIR filter is a type of a convolution, but I don't think it's possible
to write an efficient IIR filter algorithm using a convolution engine 
after all, a convolution engine should be designed to deal with a FIRs. Not
to mention that common IIR filters have 4 (LP, HP, BP, N) kernels, which
would be really inefficient for a FastConvolution algorithm, even if it
supported FIR. And as far as IIR filter performance goes, I think SIMD
instructions offer very little usefulness in IIR algorithms, since they're
so linear.

 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 14:12:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC