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: Wed, 20 Jun 2012 01:14:21 +0000
To: public-audio@w3.org
Message-Id: <E1Sh9Uz-0003Us-RQ@jessica.w3.org>

--- Comment #30 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-06-20 01:14:21 UTC ---
(In reply to comment #29)
> (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?

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. :)

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 Wednesday, 20 June 2012 01:14:24 UTC

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