- From: T.V Raman <raman@google.com>
- Date: Tue, 15 Jun 2010 11:35:55 -0700
- To: robert@ocallahan.org
- Cc: public-xg-audio@w3.org
Glad to see we have alternatives to pick from. Complexity is something we should avoid --- but in my experience, defering the details to "implementation in JS will work it out" usually does not lead to interoperability. Let's separate implementation language/ implementation layer from what we specify --- whether in JS or C++, interoperable implementations require clear and precise specification Robert O'Callahan writes: > > That API looks extremely complicated. It looks like it will be a huge amount > of work to get a precise spec with interoperability across diverse > implementations. > Dave Humphrey's proposed API ( https://wiki.mozilla.org/Audio_Data_API ) is > far simpler because it leaves almost all audio processing to JS. This "Web > Audio API" proposal has a section "Javascript Issues with real-time Processing > and Synthesis:" which lists several problems, but they boil down to two > underlying issues: > 1) JS is slower than native code. > 2) Processing audio on a Web page's "main thread" has latency risks. > Issue #2 can be addressed by extending the Audio Data API so it can be used > from Web Workers. > For issue #1, there is experimental data showing that many kinds of effects > can be done "fast enough" in JS. See the Audio Data API demos, and > https://bugzilla.mozilla.org/show_bug.cgi?id=490705#c49 for some performance > numbers. Certainly there's still a performance gap between current JS > implementations and hand-vectorized code, but it seems to me more profitable > to work on addressing that gap directly (e.g. improving JS implementations, or > adding vector primitives to JS, or providing a library of standard signal > processing routines that work on WebGLArrays, or even NaCl/PNaCl) than > hardcoding a ton of audio-specific functionality behind a complex API. The > latter approach will be a lot more work, not reusable beyond audio, and always > limited, as people find they need specific effects that aren't yet supported > in the spec or in the browser(s) they want to deploy on. > Rob > -- > "He was pierced for our transgressions, he was crushed for our iniquities; the > punishment that brought us peace was upon him, and by his wounds we are > healed. We all, like sheep, have gone astray, each of us has turned to his own > way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Tuesday, 15 June 2010 18:36:27 UTC