Re: ScriptProccessor events are stopping atfer a short while

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

Received on Tuesday, 19 March 2013 19:33:53 UTC