- From: Karl Tomlinson <karlt+public-audio@karlt.net>
- Date: Wed, 13 Aug 2014 09:30:07 +1200
- To: Chris Wilson <cwilso@google.com>
- Cc: "Srikumar K. S." <srikumarks@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <olivier.thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>
Though it may be possible to fix, we don't need to fix the old ScriptProcessorNode for offline contexts, because the lack of "working" implementations means no need to maintain backward compatibility, for offline contexts. There is one case however where the old ScriptProcessorNode was usable in an offline context, provided the OfflineAudioContext length is not too large, ScriptProcessorNode with zero output channels provides a means to examine the stream at any node in the offline graph. If the length is large, it also provides a mechanism to DoS the main thread... Chris Wilson writes: > I suspect it's POSSIBLE (though I haven't fully thought it through) for > offlineaudiocontexts to fix this, by spinning waiting for the > (asynchronous) responses from the main thread. It seems rife with deadlock > opportunities, though. There's been a request to examine how one would > utilize multiple cores in offlineaudiocontext processing, and I haven't > thought that through fully yet. > > > On Tue, Aug 12, 2014 at 2:18 AM, Srikumar K. S. <srikumarks@gmail.com> > wrote: > >> >> One suggestion in any case - forbid creation of main thread script >> processor node in offline audio contexts (by throwing an exception or >> removing the createScriptProcessor method from OfflineAudioContext. The >> spec doesn’t do justice to this case and neither do implementations. It >> will send a clear signal to devs that it is not meant to be used with the >> offline context. >> >> -Kumar >> >> >> On 12 Aug 2014, at 8:17 am, Robert O'Callahan <robert@ocallahan.org> >> wrote: >> >> On Tue, Aug 12, 2014 at 7:40 AM, Chris Wilson <cwilso@google.com> wrote: >> >>> That is precisely why I highlighted this risk. >>> >>> ScriptProcessors are certainly used today. I don't think it's horrific >>> to consider switching it over (and then off), but I do think it will take a >>> concerted, cooperative effort to do so. I think at the very least Mozilla >>> and Chrome (and ideally Safari, too) would need to support the new version >>> in roughly the same timeframe, would need to throw a "deprecation warning", >>> and would need to have a concerted plan to shut off the old version in >>> roughly the same timeframe, too. Oh, and make sure IE doesn't support the >>> old one at all. :) >>> >>> We are getting a fair bit of heat for turning off old bits in Chrome, so >>> believe me, I'm not taking this lightly. I just think the previous >>> incarnation is very bad. >>> >> >> I don't think we should remove anything from the spec until we're >> confident that we can drop support. >> >> Furthermore, I think there are two use-cases where the current main-thread >> API is actually OK: >> -- Capturing and analyzing audio data, i.e., a pure sink. >> -- Generating audio data, i.e., a pure source. >> The current main-thread API only really sucks when you're trying to take >> input and produce output. Is there disagreement about that? >> >> If not, then I think we should keep the main-thread API (and introduce the >> new API to handle scripted processing). >> >> Rob >> -- >> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo >> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo >> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo >> owohooo >> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o >> oioso >> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo >> owohooo >> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro >> ooofo >> otohoeo ofoioroeo ooofo ohoeololo. >> >> >>
Received on Tuesday, 12 August 2014 21:31:39 UTC