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, 13 Jun 2012 18:07:28 +0000
To: public-audio@w3.org
Message-Id: <E1Serya-0001cg-W1@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #12 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-06-13 18:07:28 UTC ---
(In reply to comment #11)
> Not quite the same thing as audio processing, but we're trying to limit
> all the new XHR features in main thread to async only. Sync is occasionally
> easier
> to use, but it will just fail (cause bad user experience) in the main thread.
> (And yes, the change to limit certain sync behavior to workers only broke
> various libraries.)
> 
> Similarly, JS audio processing is guaranteed to fail on the main thread
> in reasonable common cases. So, IMHO, all the JS audio processing
> should happen in background threads.

I agree it should, but I don't think it will. What should an emulator/VM
developer do? Render off main-thread as well? MSP API would have been a perfect
fit for that use case, given it's ability to process video as well... Analyzing
the byte code of those existing games and other programs and isolating the
audio code to another thread doesn't sound very feasible.

-- 
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, 13 June 2012 18:07:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 13 June 2012 18:07:40 GMT