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

I would suggest that although this is POSSIBLE (echoing what Chris said, including the caps) it’s not yet NECESSARY (my emphasis :-). Also I suspect that parallelizing offline audio might benefit from some declarative action from developers to enable it and describe where it is safe or desirable to do so within the graph — not sure yet.

In the meantime I think it would be fine to table the idea of multicore usage by offline audio context until further study can take place. It’s not going to be possible in a real-time audio context either, so this is not outright disadvantaging offline usage. 

…Joe



On Aug 12, 2014, at 2:12 PM, Chris Wilson <cwilso@google.com> wrote:

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



.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"