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: Fri, 15 Jun 2012 12:58:47 +0000
To: public-audio@w3.org
Message-Id: <E1SfW6x-0005rT-Bq@jessica.w3.org>

--- Comment #15 from Marcus Geelnard (Opera) <mage@opera.com> 2012-06-15 12:58:46 UTC ---
(In reply to comment #12)
> I agree it should, but I don't think it will. What should an emulator/VM
> developer do? Render off main-thread as well?

I guess it depends a lot on what kind of system you want to emulate, and to
what extent you need CPU cycle exact state coherence (e.g. do you want to
emulate a few popular games, or do you want to implement a fully functional
virtualization of a machine?).

For instance for implementing a SID chip for a C=64 emulator, I'd imagine that
you can simply post time-stamped messages from the main thread to an audio
worker (possibly batched as a time-stamped command buffer per frame or
whatever), where the worker implements all SID logic. A similar solution should
work for the NES sound HW too, I guess.

For emulating the Paula chip on the Amiga, you'd have more problems since it
uses DMA for accessing CPU-shared memory. On the other hand, I think you should
be able to come quite far by setting up a node graph that effectively emulates
the Paula chip using automation for timing etc, eliminating a lot of the
problems that you would otherwise have with a 100% JS-based mixer.

In any event, this does strike me as a show-stopper for having audio processing
in workers. Especially given that machine emulators are usually quite odd, both
in terms of architecture and actual use cases.

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 Friday, 15 June 2012 12:58:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:59 UTC