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

Re: Multichannel files and ChannelSplitter channel layout issue

From: Michael Weitnauer <weitnauer@irt.de>
Date: Fri, 18 Nov 2016 08:03:16 +0100
Cc: Vincent Jousse <contact@ftsoftware.fr>, public-audio@w3.org
Message-Id: <D3889E89-E495-427D-B67A-16E7227DDB40@irt.de>
To: Hongchan Choi <hongchan@google.com>
Hi, 

I ran into the same issue when I started using multichannel audio for a different purpose (https://github.com/IRT-Open-Source/bogJS <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. 

Hence, I implemented a simple test to detect the decoded order of the channels with some special test files (containing different sinus tones for each channel). It works very well but as I recently found out, it caused me some headaches when I started to test it on different mobile devices & browsers (some browsers refuse to execute the audio.play() command without user gesture…). See https://github.com/IRT-Open-Source/bogJS/blob/master/src/channelorder_test..js <https://github.com/IRT-Open-Source/bogJS/blob/master/src/channelorder_test.js> and https://github.com/IRT-Open-Source/bogJS#the-channel-order-detection-class <https://github.com/IRT-Open-Source/bogJS#the-channel-order-detection-class>

Happy to share some more background!

Michael



> Am 17.11.2016 um 19:52 schrieb Hongchan Choi <hongchan@google.com>:
> 
> Hello,
> 
> I discovered the same issue - the multichannel audio decoding in Chrome and Safari producing different results. To solve this issue, Omnitone uses a router object:
> https://github.com/GoogleChrome/omnitone#foarouter <https://github.com/GoogleChrome/omnitone#foarouter>
> 
> The FOARouter is a simple collection of 1 splitter and 1 merger. It can dynamically remap the channel layout when it's needed.
> 
> It's not ideal that you have to sniff the browser and have a different code path, but there is not much we can do. Chrome decodes the file with the built-in FFMPEG, but Safari uses the OS-provided decoder. The spec does not mandate the channel layout order yet so it is entirely up to the browser implementors.
> 
> FWIW, I believe the channel layout is should be a part of HTMLMediaElement, not the Web Audio API.
> 
> -Hongchan
> 
> On Thu, Nov 17, 2016 at 10:42 AM Vincent Jousse <contact@ftsoftware.fr <mailto:contact@ftsoftware.fr>> wrote:
> Hi,
> 
> I’ve just created a simple audio graph with a MediaElementAudioSourceNode connected to ChannelSplitterNode with 6 outputs. The MediaElement's source is a multichannel (5.1) m4a file.
> Only the first ChannelSplitterNode’s output is connected to the audio context’s AudioDestinationNode.
> I get different behaviors on Chrome and Safari : Chrome plays the front-left channel whereas Safari plays the front-center channel.
> 
> Is there anyway to « normalize » the channel splitter behavior ? Or should I create a bug on the WebAudioAPI to block the channel order as it is done for the up/down mixing ?
> 
> Vincent
> 
> 
> 
> 

---------------------------------------------------------
Michael Weitnauer
AV Technologies

Institut fuer Rundfunktechnik GmbH (IRT)
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstr. 60, D-80939 Muenchen, Germany

Email: weitnauer@irt.de          
Web: http://www.irt.de
Phone: +49 89 32399-387
Mobile: +49 15256341211


Managing director:  Dr. Klaus Illgner-Fehns
Registration court:  Munich Commercial, Register No. B 5191
Received on Friday, 18 November 2016 07:21:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 18 November 2016 07:21:53 UTC