Closed Bug 906966 Opened 8 years ago Closed 8 years ago

WebAudio Assertion failure: isInputGood [@WebCore::HRTFPanner::pan]


(Core :: Web Audio, defect)

Not set



Tracking Status
firefox25 --- fixed
firefox26 --- fixed


(Reporter: posidron, Assigned: karlt)



(Keywords: assertion, crash, testcase, Whiteboard: [blocking-webaudio-])


(4 files)

Attached file callstack
QA Contact: karlt
Blocks: 865241
Assignee: nobody → karlt
QA Contact: karlt
The spec says "The audio stream from the input will be either mono or stereo,
depending on the connection(s) to the input."

That is the case with defaults channelCount = 2 and channelCountMode = clamped-max, but we need to keep those restrictions when these values are changed.

We could try to enforce the input stream requirement by throwing when trying
to set channelCount > 2, but we'd have to also prevent channelCountMode from
being set to "max" for that to be effective.

AudioDestinationNode is similar about restricting valid channelCount values,
but I don't see any restriction on channelCountMode, providing the possibility
of circumventing channelCount.

I may need to go to public-audio.
I think the sane way to fix this is to not allow channelCount and channelCountMode to be modified on this node, it would be nice if you could bring that up on public-audio.

In the mean time, an easy way to fix this would be to make AudioNode::SendChannelMixingParametersToStream virtual, and override it in PannerNode and just send 2 and Clamped_max to the AudioNodeStream.
Posted <> to public-audio, but it hasn't been published on the list, yet.
Whiteboard: [blocking-webaudio-]
The specified behavior is discussed in

This essentially reverts the ScriptProcessorNode code changes in bug 867511.

Blink's ScriptProcessorNode is consistent with the spec, using only the
numberOfInputChannels parameter of the createScriptProcessor() method (not
channelCount) to determine the number of inputBuffer channels to pass in the
AudioProcessingEvent.  Not certain but the AudioNode::channelCount property may cause some up/down mixing to an intermediate |channelCount| channels before up/down mixing again to numberOfInputChannels.  That second mix always uses
ChannelInterpretation = Speakers, which may not be as expected.  An
intermediate mix seems more of a quirk than a feature.

I think there would be little value in being able to control the number of
input channels without some control of the number of output channels.
Attachment #798681 - Flags: review?(ehsan)
Attachment #798680 - Flags: review?(ehsan) → review+
(In reply to Karl Tomlinson (:karlt) from comment #5)
> Created attachment 798680 [details] [diff] [review]
> limit ConvolverNode and PannerNode input channel count through channelCount
> and channelCountMode
> This is the approach of comment 2 and comment 3 presented without opposition
> in
> I can add tests.

Please do!
Attachment #798681 - Flags: review?(ehsan) → review+
Depends on: 912474
Whiteboard: [blocking-webaudio-] → [blocking-webaudio-][checkin-needed-aurora]
You need to log in before you can comment on or make changes to this bug.