874024 - [Web Audio API] can't create a JavaScriptNode with no Inputs

Status: RESOLVED FIXED

(Core :: Web Audio, defect)

Description

[boblemarin]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

I want to use a JavaScript node as sound generator in my WebAudioAPI-enabled application. It should have two outputs for stereo, but it does not need to have any inputs (it just generates signal).


Actual results:

When creating my node like this :
  context.createJavaScriptNode(2048,0,2); // error

I get the following error :
  IndexSizeError: Index or size is negative or greater than the allowed amount

If I add at least one (unused) input, the error vanishes.
  context.createJavaScriptNode(2048,1,2); // fine



Expected results:

The Web Audio specs state that "It is invalid for both numberOfInputChannels and numberOfOutputChannels to be zero", so the output-only version of the code should work, as it does in other browsers.

Comment 1

[boblemarin]

Attachment: jsFiddle link

Created a small fiddle with the two lines of code required to generate the error...

Comment 2

[boblemarin]

http://jsfiddle.net/WjKtD/

Comment 3

[Loic]

Comment on attachment 751653 [details]
jsFiddle link

>http://jsfiddle.net/WjKtD/

Comment 4

[(no longer active)]

The spec has actually be re-worded to say "It is invalid for either numberOfInputChannels or numberOfOutputChannels to be zero."  The reason behind this is that we still need to provide an inputBuffer on the event object, which is going to have a number of silent channels, and we can't create an AudioBuffer with 0 channels.  Therefore, Gecko's behavior matches the spec, and if WebKit/Blink accept this code, that is a bug in their implementation.

To get your code working, I suggest you just pass in 1 and ignore the inputBuffer attribute on the events that you will receive.

Comment 5

[boblemarin]

OK if the specs say so, but I can't find that re-wording in the current published spec. Could you please provide me with a link to that new version, so I can refer to the correct document ?

The workaround you mention is the one I have been using, but I thought it was a bit tricky because there was no mention of that limitation in the available references.

Thanks for the informations.

Comment 6

[(no longer active)]

Not sure what version of the spec you're looking at, but you need to look at <https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html> I think.

Also, I'm talking to Chris Rogers about this right now, and we may end up reverting that change, in which case I'll reopen this bug and update Gecko to match that, but let's see how that goes.  The workaround I suggested would still make sense though.

Comment 7

[boblemarin]

OK, in fact I was looking at the specs for the ScriptProcessorNode where it still states that "It is invalid for both numberOfInputChannels and numberOfOutputChannels to be zero", while the spec for the createScriptProcessor()  method says that "it is invalid for either numberOfInputChannels or numberOfOutputChannels to be zero".

IMHO there is some contradiction in there. And I find the non-zero limitation counter-intuitive, because in the "hardware world", I would not understand why an instrument has to have an input to be able to output something.

Maybe the implementation could manage that limitation behind the scene, hiding it from the user.


********
createScriptProcessor()
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#methodsandparams-AudioContext

ScriptProcessorNode
http://www.w3.org/TR/webaudio/#ScriptProcessorNode

Comment 8

[(no longer active)]

(In reply to comment #7)
> OK, in fact I was looking at the specs for the ScriptProcessorNode where it
> still states that "It is invalid for both numberOfInputChannels and
> numberOfOutputChannels to be zero", while the spec for the
> createScriptProcessor()  method says that "it is invalid for either
> numberOfInputChannels or numberOfOutputChannels to be zero".

Right, like I said this was a recent change in the spec which we might revert.  I will update this bug when we reach a decision there.


> createScriptProcessor()
> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#methodsandparams-AudioContext
> 
> ScriptProcessorNode
> http://www.w3.org/TR/webaudio/#ScriptProcessorNode

FWIW you should probably look at the first version of the spec.  It is changing a bit these days, but it's the latest version.

Comment 9

[(no longer active)]

The spec change was reverted:

https://dvcs.w3.org/hg/audio/rev/604be68da08f
https://dvcs.w3.org/hg/audio/rev/9a5c5d423979

Comment 10

[(no longer active)]

Attachment: Patch (v1)

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 752957 [details] [diff] [review]
Patch (v1)

Review of attachment 752957 [details] [diff] [review]:
-----------------------------------------------------------------

oops, I should have caught this.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Arguably we should just remove this limit altogether. Sure, an no-input no-output ScriptProcessorNode is not useful, but it's not harmful either so it's simpler to allow it.

Comment 13

[(no longer active)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #12)
> Arguably we should just remove this limit altogether. Sure, an no-input
> no-output ScriptProcessorNode is not useful, but it's not harmful either so
> it's simpler to allow it.

That's fine by me.  Can you please bring it up on the list?

Comment 14

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c5ac92c2881e

Comment 15

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/c5ac92c2881e

Comment 16

[(no longer active)]

Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.