This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21777 - Specify that audioprocess events should be dispatched to ScriptProcessorNodes when they're not connected to an output node
Summary: Specify that audioprocess events should be dispatched to ScriptProcessorNodes...
Status: CLOSED FIXED
Alias: None
Product: AudioWG
Classification: Unclassified
Component: Web Audio API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: TBD
Assignee: Chris Rogers
QA Contact: public-audio
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-23 03:55 UTC by Ehsan Akhgari [:ehsan]
Modified: 2013-09-05 16:48 UTC (History)
6 users (show)

See Also:

Attachments

Description Ehsan Akhgari [:ehsan] 2013-04-23 03:55:38 UTC 
I think it would not make any sense to dispatch events to those nodes which are not connected to any output.  We should spec this one way or another, anyway.
Comment 1 Alan deLespinasse 2013-05-29 20:45:25 UTC 
Note that ScriptProcessorNode allows having zero outputs. It makes sense to have a ScriptProcessorNode with one input and zero outputs, for example to do some kind of analysis on the audio without producing a signal. In this case the node can't be connected to an output, but obviously it should generate events. (Though currently this doesn't seem to work, at least in the stable version of Chrome.)

I'm not sure it would be wrong to generate events even if there are outputs which aren't connected, considering that the event handler may have side effects. But yes, the spec should specify this.
Comment 2 Robert O'Callahan (Mozilla) 2013-05-29 21:32:10 UTC 
I agree with Alan.

We could stop dispatching events if the node is not connected to any input OR output.
Comment 3 Ehsan Akhgari [:ehsan] 2013-05-29 22:23:15 UTC 
Actually now that I have more experience *using* ScriptProcessorNode, I've changed my mind, and I think it totally makes sense for it to receive events even if its not connected to anything, as it gives you an inspection tool, similar to AnalyserNode.

The good news is that that is what Gecko does already.  The bad news is that WebKit/Blink will need to change their implementation to match.

Leaving this to spec the desired behavior at any rate.
Comment 4 Marcus Geelnard (Opera) 2013-05-30 12:37:13 UTC 
I agree that a ScriptProcessorNode should receive events even if it has at least one input or one output.

I still think that it's a valid goal to make it possible to mimic all node types with the ScriptProcessorNode. In order to create a source node (e.g. an Oscillator), you shouldn't have to have any inputs, and in order to create an analyzer node, you shouldn't have to have any outputs.
Comment 5 paul@paul.cx 2013-08-30 16:44:02 UTC 
Let's spec that OscillatorNode is not required to have both input AND output, that is, that having input OR output is enough for events to be fired.

Is everybody okay with that?
Comment 6 Chris Wilson 2013-08-30 17:55:27 UTC 
I think you mean ScriptProcessorNode, but yeah.
Comment 7 paul@paul.cx 2013-08-30 18:05:15 UTC 
Indeed, sorry, I was in the middle of something else.
Comment 8 Ehsan Akhgari [:ehsan] 2013-09-04 14:48:56 UTC 
(In reply to comment #5)
> Let's spec that OscillatorNode is not required to have both input AND
> output, that is, that having input OR output is enough for events to be
> fired.
> 
> Is everybody okay with that?

Yes, although the first part should be true for all node types.
Comment 9 Olivier Thereaux 2013-09-05 16:47:06 UTC 
Addressed in https://dvcs.w3.org/hg/audio/rev/92183159c02b