W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Jun 2012 23:15:33 +0000
To: public-audio@w3.org
Message-Id: <E1Sh7e1-000658-TC@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #29 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2012-06-19 23:15:33 UTC ---
(In reply to comment #26)
> 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?

-- 
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 Tuesday, 19 June 2012 23:15:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 23:15:52 GMT