I think the general idea of adding APIs for ScriptProcessorNode with
Workers is uncontroversial. (Personally I'd recommend not creating a new
Worker class and instead just dispatching new messages to existing workers,
but we can debate that later.) However I think there's been a feeling we
should defer that to some level 2 spec.
Main-thread ScriptProcessorNodes are useful. If you only want to monitor
produced audio and you're not latency-sensitive, they work perfectly well.
If you're generating audio they can still work quite well if the UA
implements them carefully. For example, in Gecko we adaptively increase
buffering to mostly eliminate glitching. The reality is that a lot of the
things you might want to do when generating audio data (e.g. implement a
game emulator) can only be done on the main thread today, so for many
applications audio-generating Workers would not be immediately useful.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
*