Welcome!

Hi all,

I'm glad to see that people take interest in this Community Group.

Since this group was created quite recently, I do not want to rush to 
the formal parts just yet (scope of work, decision processes, 
communication preferences, selecting a chair, etc). Let's wait a bit 
until more people have had the chance to join etc.

Until then, I'll just briefly explain the background that lead up to the 
creation of this Community Group:

It began as a series of discussions in the Web Audio working group, 
regarding the possibilities of doing low-latency, high performance audio 
signal processing in JavaScript (specifically in the context of an 
AudioProcessingEvent [1]).

Real-time audio processing entails a few requirements that make it 
slightly more difficult than some other forms of data and signal 
processing. Especially important is low latency (typically microseconds 
rather than milliseconds), low CPU overhead, and for garbage collected 
languages such as JavaScript the GC activity must be minimal.

Considering the design of the Web Audio API, where the data is made 
available in a typed array on the JavaScript heap and come in bursts of 
a few hundred samples at a time, the most viable option is to do all the 
processing on the CPU. On the other hand, using WebGL/GLSL or other 
GPU-based APIs, such as WebCL, would quite likely fail to meet the 
latency requirements.

...which leaves us with the CPU load. While modern JavaScript engines 
are quite impressive, they usually fail to utilize the instruction level 
parallelism provided by SIMD instructions, which becomes the most 
important missing link for achieving performance levels in JavaScript on 
par with hand crafted native code (e.g. C++ with SIMD intrinsics).

Based on those conditions, I tried to come up with a fairly minimal API 
that would be easy to implement in a Web client, yet bring cross 
platform SIMD capabilities to the Web platform. The result after a few 
iterations was an API that I called the "DSP API" [2], which later 
matured into what is now called the "Web Array Math API" [3].

While the API was designed with audio signal processing in mind, it 
should of course be useful for other things too. For instance, you can 
check some early usage examples [4] (non-accelerated when you use the JS 
polyfill).

Now, after some proof-of-concept testing the time has come to involve 
more people and take the work forward. ...which is why I created this 
groups.

I suspect that the first things we'll try to tackle in this group (apart 
from practical & formal issues) are the high level aspects of the 
proposed API (such as its scope, its general design, use cases and its 
merits and flaws compared to other similar technologies), and provided 
that we reach some sort of consensus we'll move on to lower level 
aspects of the API (such as interface design, missing/superfluous 
methods, precision requirements, testability, etc).


Regards,

   Marcus Geelnard


[1] 
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AudioProcessingEvent
[2] http://people.opera.com/mage/dspapi/
[3] http://opera-mage.github.io/webarraymath/
[4] http://opera-mage.github.io/webarraymath/demos/

-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software

Received on Tuesday, 19 November 2013 13:57:49 UTC