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

Yeah, I meant "I've seen a request that multiple cores be able to be used
from within a single offlineaudiocontext" - e.g., a heavy-cost script
processor being passed off to another core.


On Tue, Aug 12, 2014 at 10:49 AM, Raymond Toy <rtoy@google.com> wrote:

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