Re: AudioContext.maxChannelCount

On Tue, May 28, 2013, at 02:47 AM, Chris Rogers wrote:




On Mon, May 27, 2013 at 9:30 AM, Paul Adenot <[1]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)...

(1) makes sense indeed, since authors can achieve (2) pretty easily.
This will most likely require having a second channel at the audio
output level, that is silent, because most of the audio backend library
(that are not intended for musical use) will upmix mono to stereo.

It is actually useful to spec it that way to use external
software/hardware with Web Audio.




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.

I think we agree, then.




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.

32 ought to be enough for anybody. I think it is high enough to not
prevent use cases.




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.

This makes sense as well.

Paul.

References

1. mailto:paul@paul.cx