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/24244488@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#29) by Jussi Kalliokoski on W3C Bugzilla. Wed, 20 Jun 2012 01:14:21 GMT

(In reply to [comment #29](#issuecomment-24244480))
> (In reply to [comment #26](#issuecomment-24244453))
> > Still, no matter what we do, in some cases audio will not work as expected,
> > will miss refills, and there's nothing we can do about it.
> 
> With JS audio produced in Workers, the browser should be able to make audio
> work reliably in any situation short of complete overload of the device.
> 
> With JS audio on the main thread, audio will start failing as soon as a
> badly-behaving page happens to share the same main thread as the audio page.
> 
> That is a huge difference.
> 
> > What we can do,
> > however, is give the proper tools to handle these situations, including main
> > thread audio processing that doesn't have to resort to manually transferring
> > audio to a worker (or graphics to the main thread either), because that's even
> > more expensive and likely to fail.
> 
> For use-cases such as "run an emulator producing sound and graphics", the best
> solution is to provide Worker access to canvas as well as audio. Then you can
> have reliable audio and a reliable frame rate as well.
> 
> Are there any other use-cases that are problematic for audio production in
> Workers?

If Workers get access to canvas, at least I can't think of a (valid) reason why anyone would want to process audio in the main thread. :)

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244488
Received on Wednesday, 11 September 2013 14:30:37 UTC

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