Re: ScriptProccessor events are stopping atfer a short while

> This has been a major source of confusion and I think we should change this, and in general we should treat ScriptProcessorNodes that have zero inputs as the sources that they are, and a zero-input ScriptProcessorNode should be kept from garbage collection as long as it's connected directly or indirectly to an active sink.

This seems like a reasonable suggestion ... if script processor nodes supported multiple inputs. Currently these nodes always have one input and one output. What we pass to the createScriptProcessor is the number of *channels* in the single input. Detecting sources using zero for "numberOfChannels" may be acceptable as "better than what went before", but the right way to identify source nodes, I'd expect, is nodes with no inputs at all - i.e. "node.numberOfInputs" should be 0 if a node is to be considered a source node.

-Kumar

On 20 Mar, 2013, at 1:03 AM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:

> The bug against Chromium can be found here: https://code.google.com/p/chromium/issues/detail?id=82795
> 
> Actually this reminds me... Is this actually a bug by the spec? I don't think the current spec has any special rules for the ScriptProcessorNode GC, so following the AudioNode garbage collection information in the spec, it looks like ScriptProcessorNodes shouldn't be kept around if there aren't any references to them. This has been a major source of confusion and I think we should change this, and in general we should treat ScriptProcessorNodes that have zero inputs as the sources that they are, and a zero-input ScriptProcessorNode should be kept from garbage collection as long as it's connected directly or indirectly to an active sink.
> 
> Cheers,
> Jussi
> 
> On Tue, Mar 19, 2013 at 3:51 PM, Srikumar Subramanian <srikumarks@gmail.com> wrote:
> This is a long standing bug in the webkit implementation with a known workaround. If you keep around a *global* reference (in the window object itself) to either the onaudioprocess function or the script processor node itself, the arbitrary stopping won't happen. 
> 
> Best,
> -Kumar
> 
> On 19-Mar-2013, at 4:40 PM, Peter van der Noord <peterdunord@gmail.com> wrote:
> 
>> I may be doing something wrong here, it's been a while since i created a script-processor node, but my event-handler for a scriptprocessor seems to stop firing pretty quickly.
>> 
>> Fiddle here: http://jsfiddle.net/7LZAJ/
>> 
>> Strangely, the fiddle sometimes runs fine the first time, but when i refresh after that it does what happens locally here as well: the eventhandler does not get called anymore (and the remaining noisebuffer is repeated). The writing of the noise into the buffer has nothing to do with it, if my eventhandler only  logs something to the console it will just stop shortly after starting (always after the same number of repetitions).
>> 
>> Am i overlooking something?
>> 
>> 
>> Peter
>