4 ms·

Wasn't Mozilla's proposed audio API simpler? AFAIK it was beaten out by Google's because people wanted a richer API and lower latencies. https://web.archive.or

Wasn't Mozilla's proposed audio API simpler? AFAIK it was beaten out by Google's because people wanted a richer API and lower latencies. https://web.archive.org/web/20120505042746/https://developer.mozilla.org/en/Introducing_the_Audio_API_Extension https://web.archive.org/web/20120505042746/https://developer...

spookie 3y ago
Did people want lower latencies though? It seems a bit absurd given other compounding factors that have a play on that.
jsheard 3y ago
IIRC it turned out that way in large part because realtime audio is very sensitive to performance hitches, and idiomatic JS is hitchy by nature due to relying on garbage collection, so they wanted to hoist as much as possible up into native code provided by the browser. If WASM had existed at the time it would have been easier to make the case for just exposing a simple raw audio interface instead.
- capitainenemo 3y ago
  Well... Mozilla had ASM.js at the time. In part to showcase their superior performance with certain portions of JS compared to V8 - at the time I remember the things like console emulators preferring Mozilla's JS engine due to it offering more reliable performance than V8 on the tight loops and large switches. Mozilla was also demonstrating how their engine could offer comparable performance to Google NaCl in an image processing demo which was conceived to show how NaCL could cover limitations in V8 at the time. I wonder if we might well have had more traction with Mozilla's approach and ASM.js if V8 had had similar features. Oh well. Is what it is, and Mozilla (and Microsoft and Apple) did at least manage to get WASM which has been super useful even outside of browsers.
  - capitainenemo 3y ago
    (That is, I'm pretty sure ASM.js uses same trick WASM does given it was the predecessor - just preallocate a ton of memory in an array, and work with primitive types, and no GC to worry about most of the time)

spookie 3y ago

Did people want lower latencies though? It seems a bit absurd given other compounding factors that have a play on that.

jsheard 3y ago

IIRC it turned out that way in large part because realtime audio is very sensitive to performance hitches, and idiomatic JS is hitchy by nature due to relying on garbage collection, so they wanted to hoist as much as possible up into native code provided by the browser. If WASM had existed at the time it would have been easier to make the case for just exposing a simple raw audio interface instead.

capitainenemo 3y ago
Well... Mozilla had ASM.js at the time. In part to showcase their superior performance with certain portions of JS compared to V8 - at the time I remember the things like console emulators preferring Mozilla's JS engine due to it offering more reliable performance than V8 on the tight loops and large switches. Mozilla was also demonstrating how their engine could offer comparable performance to Google NaCl in an image processing demo which was conceived to show how NaCL could cover limitations in V8 at the time. I wonder if we might well have had more traction with Mozilla's approach and ASM.js if V8 had had similar features. Oh well. Is what it is, and Mozilla (and Microsoft and Apple) did at least manage to get WASM which has been super useful even outside of browsers.
- capitainenemo 3y ago
  (That is, I'm pretty sure ASM.js uses same trick WASM does given it was the predecessor - just preallocate a ton of memory in an array, and work with primitive types, and no GC to worry about most of the time)