W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Sun, 08 Jul 2012 06:24:37 +0000
Message-Id: <E1Snkv7-0003RP-BW@jessica.w3.org>
To: public-audio@w3.org

Grant Galitz <grantgalitz@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |grantgalitz@gmail.com

--- Comment #32 from Grant Galitz <grantgalitz@gmail.com> 2012-07-08 06:24:36 UTC ---
Yeah, I can tell this talk about an emulator producing audio on the main thread
and sending off the audio data to a worker is related to JS GBC using XAudioJS
with the MediaStream Processing API in use. :P

I personally have to use the main thread for compatibility reasons with legacy
browsers lacking web worker support. Essentially creating a second version of
the emulator for webworker capable browsers seems like a big hack. Sending
audio off from the main thread to the worker is very easy to do, but the i/o
lag is off the charts (almost a half a second in some cases), as seen with
experimentation with the mediastream api.

To see what it would look like to sync audio from the main thread to the
main thread:


The question to be asked: Why not allow the js developer to select either a web
worker or main thread usage for outputting audio? Locking audio to one or the
other seems to only limit options here.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Sunday, 8 July 2012 06:24:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC