Re: AudioContext.maxChannelCount

On Mon, May 27, 2013 at 9:30 AM, Paul Adenot <paul@paul.cx> wrote:

> Hi,
>
> Currently implementing |AudioContext.maxChannelsCount| in Gecko, I
> wonder why conforming implementations should return 0 if the channel
> count cannot be changed by the author.
>
> For a regular |AudioContext.destination|, it seems to me that any
> implementation that supports the default, i.e. stereo, could trivially
> support mono-output (simply by adding a final down-mixing step before
> writing the data to the audio sink). Support for multichannel output is
> easily tested for using |AudioDestinationNode.maxChannelsCount| (which
> would be > 2 if the hardware supports more than two channels).
>

Yes, I think that might be reasonable.  The reason I avoided this case is
there is a subtlety when the hardware is actually stereo.  In that case,
when you configure the .channelCount to 1 (mono), would you expect:

1) the mono output to only show up in hardware channel 1?
2) Or would this be a mono down-mix which would then be (at a later stage)
presented to both L/R stereo hardware outputs?

I think (1) is the most consistent and probably what we would want.  In
order to achieve (2), we can always achieve the mix-to-mono at an earlier
stage in the graph (like with an AudioGainNode)...


>
> For an |OfflineAudioContext.destination|, it makes sense that the number
> of channels becomes non-mutable after the start of the rendering, but
> returning zero seems inconsistent. Since we are not limited by hardware
> capabilities, it would make more sense to return the number of channels
> the implementation accepts without throwing when setting the channel
> property before starting the rendering, that is somewhat arbitrary but
> should exist.
>

I think since the .channelCount is determined when the OfflineAudioContext
is constructed that it's fine to not allow changing this value afterwards.
 It doesn't in any real sense limit the possibilities of what can be
achieved.


>
> Forcing the authors to determine the upper limit of
> |OfflineAudioContext.destination.channels| for a given implementation by
> using a try/catch and a loop seems bad.
>

Yes, I agree.  One possibility is to actually spec the upper limit of this
value in the OfflineAudioContext constructor for an implementation.


>
> On a related note, maybe |MediaStreamAudioDestinationNode| could have a
> |maxChannelsCount| attribute as well.
>

My thinking here was that we could add an optional argument to
createMediaStreamDestination() to specify .channelCount.  This value is
going to be needed early on since it will often be used to send to a remote
peer where the negotiation of the stream format will need to happen at the
beginning.  In other words, it could be awkward and cumbersome to try to
change the number of channels half-way in the middle of a transmission to a
remote peer, so I was thinking we should avoid allowing it to be changed
after it's first created.


>
> Thanks,
> Paul.
>
>
>