W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

"ScriptProcessorNode is Unfit For Purpose" issue

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 26 Jul 2013 11:50:19 +1200
Message-ID: <CAOp6jLY_xWmV9ZdKcfeL=UEgAXPhdb5M1=B=h_8Za6TmCee7GQ@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC