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:56 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/113/24244517@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#34) by Robert O'Callahan (Mozilla) on W3C Bugzilla. Sun, 08 Jul 2012 22:14:53 GMT

(In reply to [comment #33](#issuecomment-24244505))
> The whole discussion about the main thread being very poor for audio streaming
> seems to be somewhat overplayed. Proper web applications that use the main
> thread should ration their event queue properly.

See comment #21.

(In reply to [comment #34](#issuecomment-24244511))
> > 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.
> 
> What about lack of hardware acceleration? That'll block audio as long as gfx is
> on the same thread as audio, which in my case is a must for low lag sync.

If you must have audio on the same thread as graphics, and that causes glitches because the device is simply overloaded, then so be it; that is unavoidable. See comment #29.

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

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