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

Re: [web-audio-api] (JSWorkers): ScriptProcessorNode processing in workers (#113)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:54 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/113/24244501@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#31) by Grant Galitz on W3C Bugzilla. Sun, 08 Jul 2012 06:24:36 GMT

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

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.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:30:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC