- From: <bugzilla@jessica.w3.org>
- Date: Sun, 08 Jul 2012 06:24:37 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415
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
worker:
main thread:
https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServer.js#L142
and
https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServer.js#L406
worker:
https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServerMediaStreamWorker.js
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