Re: Simplifying specing/testing/implementation work

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
>