Tested with http://hg.mozilla.org/integration/mozilla-inbound/rev/94a23a49ca26 + https://bugzilla.mozilla.org/show_bug.cgi?id=865253

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 <87vc2x2o7j.fsf@karlt.net> to public-audio, but it hasn't been published on the list, yet.

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.

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.

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/2ee662f747a2 https://hg.mozilla.org/integration/mozilla-inbound/rev/4d5107aea708 https://hg.mozilla.org/integration/mozilla-inbound/rev/15a71c6cb0d3

https://hg.mozilla.org/releases/mozilla-aurora/rev/16a75b0603c3 https://hg.mozilla.org/releases/mozilla-aurora/rev/b3ee30214d40 https://hg.mozilla.org/releases/mozilla-aurora/rev/93c133621e72

https://hg.mozilla.org/mozilla-central/rev/2ee662f747a2 https://hg.mozilla.org/mozilla-central/rev/4d5107aea708 https://hg.mozilla.org/mozilla-central/rev/15a71c6cb0d3