W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2015

New behavior of ChannelMergerNode

From: Hongchan Choi <hongchan@google.com>
Date: Tue, 3 Feb 2015 10:02:09 -0800
Message-ID: <CAGJqXNsfDJmOQTp4qT+RkjPribWk+2+K_f4dvkLtjCnjciVC9A@mail.gmail.com>
To: public-audio@w3.org
Cc: Raymond Toy <rtoy@google.com>, Chris Wilson <cwilso@google.com>
Hello All,

I would like to ask WG opinions on issues on ChanngerMergerNode and suggest
the new behavior.

I believe ChannlerMergerNode was originally designed to merge audio streams
from multiple input which can be changed dynamically. As we all know, this
feature is causing two critical issues:

1) It is impossible to have a static mapping between input and output when
the input connection is changing dynamically. If any input channel changes,
the output channels will be rearranged in an unexpected manner.

https://github.com/WebAudio/web-audio-api/issues/304

2) In the spec, there is no mechanism for limiting the number of
input/output channel. So it is unclear about what should happen when the
merger node is in a cyclic graph. Although the merger inside of a cycle
does not make sense, it is possible to do.

https://github.com/WebAudio/web-audio-api/issues/459


And here is my thought/proposal to solve these problems:

---
The following properties are fixed for ChannelMergerNode and InvalidState
error should be thrown when user changes them:

ChannelMergerNode.channelCount = 1
ChannelMergerNode.channelCountMode = ‘explicit’

Changed behavior:
* Each input will be summed to mono based on the specified mixing rule.
* The summed mono channel from input will be transferred to the
corresponding output channel (input_0 -> output_channel_0). If an input is
not connected (inactive or disconnected), it still counts as one silent
channel in output.
* Note that the input to output channel mapping is fixed and won’t change
the order of output channels dynamically.
---

Any thought/feedback from WG appreciated.

-- 
Hongchan
Received on Wednesday, 4 February 2015 08:17:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 February 2015 08:17:24 UTC