Re: Call for Consensus: retire current ScriptProcessorNode design & AudioWorker proposal

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.
>
>
>