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

On Tue, Aug 12, 2014 at 8:27 AM, Chris Wilson <cwilso@google.com> wrote:

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

In Chrome, it seems that each offlineaudiocontext is run in it's own
thread.

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