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 * *
Received on Thursday, 25 July 2013 23:50:47 UTC