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

RESOLVED FIXED in Firefox 25

Status

()

defect
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: posidron, Assigned: karlt)

Tracking

(Blocks 1 bug, {assertion, crash, testcase})

Trunk
mozilla26
x86_64
macOS
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox25 fixed, firefox26 fixed)

Details

(Whiteboard: [blocking-webaudio-])

Attachments

(4 attachments)

Reporter

Comment 1

6 years ago
Posted file callstack
Assignee

Updated

6 years ago
QA Contact: karlt
Assignee

Updated

6 years ago
Blocks: 865241
Assignee

Updated

6 years ago
Assignee: nobody → karlt
QA Contact: karlt
Assignee

Comment 2

6 years ago
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.

Comment 3

6 years ago
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.
Assignee

Comment 4

6 years ago
Posted <87vc2x2o7j.fsf@karlt.net> to public-audio, but it hasn't been published on the list, yet.

Updated

6 years ago
Whiteboard: [blocking-webaudio-]
Assignee

Comment 6

6 years ago
The specified behavior is discussed in http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0610.html

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)

Updated

6 years ago
Attachment #798680 - Flags: review?(ehsan) → review+

Comment 7

6 years ago
(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 http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0567.html
> 
> I can add tests.

Please do!

Updated

6 years ago
Attachment #798681 - Flags: review?(ehsan) → review+
Assignee

Updated

6 years ago
Depends on: 912474

Updated

6 years ago
Whiteboard: [blocking-webaudio-] → [blocking-webaudio-][checkin-needed-aurora]
You need to log in before you can comment on or make changes to this bug.