W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2016

Re: Multichannel files and ChannelSplitter channel layout issue

From: Hongchan Choi <hongchan@google.com>
Date: Fri, 18 Nov 2016 16:41:05 +0000
Message-ID: <CAGJqXNt1y-+TR0Km1Ejo2miNB5=310s+SRW8FKOQEJSSt9R9pA@mail.gmail.com>
To: Paul Adenot <padenot@mozilla.com>, Michael Weitnauer <weitnauer@irt.de>
Cc: Vincent Jousse <contact@ftsoftware.fr>, "public-audio@w3.org Group" <public-audio@w3.org>
Yes, I mentioned this pain point in the last W3C WebVR workshop. The
multichannel audio is still not in the category of 'the majority use case',
so browser implementors neglected it.

Since WebAudio is getting the stream from the HTMLMediaElement, so I was
expecting the element to do work for me.

On a related note, it would be really great to be able to check the valid
channel count of the original media from the MediaStream* sources. It turns
out to be there is no way to figure this out from the developer's

Why don't we start a thread in the WebAudio issue tracker and get more
people involved if needed?


On Fri, Nov 18, 2016 at 3:13 AM Paul Adenot <padenot@mozilla.com> wrote:

> On Fri, Nov 18, 2016 at 8:03 AM, Michael Weitnauer <weitnauer@irt.de>
> wrote:
> Hi,
> I ran into the same issue when I started using multichannel audio for a
> different purpose (https://github.com/IRT-Open-Source/bogJS). As I found
> out, the situation is even worse as you can absolutely not rely on
> consistent behavior of the same browser on different platforms, especially
> in the case of Firefox which uses the system decoders as far as I know. But
> I agree, even the different channel orders between the major browsers are a
> real pain.
> The plan for Firefox is to always remap to SMTPE order regardless of how
> the file was decoded. We are actively working on this, so it might not be
> available on release.
> I agree it is necessary to spec this. What would be an appropriate venue
> for this ?
> Thanks,
> Paul.
Received on Friday, 18 November 2016 16:41:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 18 November 2016 16:41:49 UTC