[cromwellian]

Isn't Web Audio based off of MacOS'x Audio API?

I think the whole point is that Javascript used to be slow, and using the CPU as a DSP to process samples prevents acceleration. Seems to me what is needed is like "audio shaders" equivalent to compute/pixel shaders, that you farm off to OpenAL-like API which can be compiled to run on native HW.

Even if you grant emscripten produces reasonable code, it's still bloated, and less efficient on mobile devices than leveraging OS level DSP capability.

[pierrec]

Modern CPUs actually make decent general purpose DSPs for audio, so I'm not sure what kind of hardware acceleration you expect. Parallelization? Audio processing is not as extremely parallelizable as video. It's somewhat parallelizable. In a classic audio filter function, each sample affects the sample that comes immediately after it, so it's not embarrassingly parallel. The best you can do is, for example, parallelize multiple independent filters, so CPU SIMD instructions often turn out to be a decent fit.

As a side note, for some common audio DSP tasks, you could presumably take better advantage of highly parallel processing by doing a fourier transform and working in the spectral domain. There has been research do do this on GPUs and it works. However, if you do this you'll have high latency, and it's not a hardware problem, it's inherent to the FFT algorithm, so it's kind of a dead end for many applications.

[TD-Linux]

While it sort of looks like that, I don't know of any non-software implementations of the API (they use some SIMD at most). The problem is that 48,000 samples per second really isn't that much, even with very complex processing. When you compare it to a 1080p screen which has to process at least 373,248,000 samples per second, it hardly seems worth it to even spin up a shader.

[iainmerrick]

Isn't Web Audio based off of MacOS'x Audio API?

I hadn't heard that, but some of the "processor node" stuff does sound familiar.

What OS X also has, though, is proper low-level low-latency sound APIs. And that's why there are so many Mac (and iOS) music apps.

[kevingadd]

It is more or less based on OS X audio, yes. The author of the Web Audio spec previously was an architect on Core Audio at Apple. He basically moved over to Google, implemented his chosen subset of Core Audio in webkit, and shipped it prefixed. Then the evangelism group got big players like Rovio to ship apps that depended on the half-baked prefixed API so it was the de-facto standard for game SFX on the web.

[iainmerrick]

Interesting! It's surprising to me that Apple (or Google?) is behind such a poor API, after Apple did such a good job with both Canvas and CSS animation.

[flohofwoe]

Even 'idiomatic' Javascript is plenty fast to generate audio samples, not to mention asm.js or WebAssembly. The latency / non-realtime nature of the 'browser loop' is the main problem (not being able to generate new sample data exactly when it is needed).