W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: limiting channel count through channelCount and channelCountMode limitations, in PannerNode et al.

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Wed, 28 Aug 2013 12:27:12 -0400
Message-ID: <CANTur_5NgB-ZSPbzEu59Fy70tgCMy4v2w1H=dhouAbWCtgQ-6A@mail.gmail.com>
To: Karl Tomlinson <karlt+public-audio@karlt.net>
Cc: "public-audio@w3.org" <public-audio@w3.org>
On Thu, Aug 22, 2013 at 9:25 PM, Karl Tomlinson <
karlt+public-audio@karlt.net> wrote:

> Some AudioNodes have limitations on the number of input channels,
> but the computedNumberOfChannels calculation in [1] currently
> doesn't necessarily consider these limitations.
> The input channel limitation is clearly spelled out for
> PannerNode, for example: "The audio stream from the input will be
> either mono or stereo, depending on the connection(s) to the
> input."
> Would it make sense to spec that an exception is thrown if a
> PannerNode's channelCount is set > 2?
>   This is similar to how AudioDestinationNode is currently spec'd
>   to handle maxChannelCount.
>   There may be a good reason to allow channelCount to be set to 1,
>   as the panning effects on stereo inputs are different from mono
>   inputs.
> I propose NOT_SUPPORTED_ERR, as when setting channelCount to zero.

I think that we should throw NOT_SUPPORTED_ERR when channelCount is set to
anything except 1 and 2, both for PannerNode and ConvolverNode.

> For channelCount to be effective in limiting the number of input
> channels, channelCountMode cannot be "max".
> Would it make sense to spec that an exception is thrown if a
> PannerNode's channelCountMode is set to "max"?


>   There may be a good reason to allow channelCountMode to be set
>   to "explicit" to force up-mixing to 2 channels, as the effects
>   of the equalpower panner on 2 duplicate channels are different
>   from a mono input.


> This approach feels more transparent to me than silently
> adjusting the computedNumberOfChannels calculation.
> [2] implies that a similar situation applies to ConvolverNode,
> and, looking at [3], I wonder whether a similar situation applies
> in ScriptProcessorNode?  See also [4].

ConvolverNode suffers from the exact same problem so the same solution
should be applied to it as well.  ScriptProcessorNode, however, doesn't
suffer from this problem, why would we want to restrict it in any way?

> It may make sense to limit channelCountMode for
> AudioDestinationNode, but [5] is advocating a different approach.
> [1]
> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#UpMix
> [2]
> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#Convolution-reverb-effect
> [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17534
> [4] http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0136.html
> [5] http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0439.html
I don't think it makes sense to apply the same restriction to

Received on Wednesday, 28 August 2013 16:28:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC