Logs : https://pantheon.corp.google.com/m/cloudstorage/b/chromiumos-test-logs/o/bugfiles/cr/600538/debug-logs_20160404-154321.tgz

Audio Files : https://pantheon.corp.google.com/m/cloudstorage/b/chromiumos-test-logs/o/bugfiles/cr/600538/6_Channel_ID.wav
https://pantheon.corp.google.com/m/cloudstorage/b/chromiumos-test-logs/o/bugfiles/cr/600538/Nums_5dot1_24_48000.wav

These audio files are also working on 50.0.2661.16/7978.7.0. Issue might be included after this build.

Looks like the CL for software gain broke it.
I will check it
https://crosland.corp.google.com/log/7978.7.0..7978.36.0

With R49 Cras on 8150.0.0 image, the issue is the same.
So, this is not related to CL in #4. It looks more like Chrome issue because cras_test_client can play the file correctly with down mixing.

cras_test_client --playback_f /usr/local/6_Channel_ID.wav --num_channel 6

However, if the file is played through Chrome, the playback does not even start.
In /var/log/chrome/chrome
I got

[1:1:0406/153946:ERROR:render_media_log.cc(21)] MediaEvent: PIPELINE_ERROR pipeline: decode error

 whenever I hit play button.

+dale

Any ideas on recent changes that would affect 6-channel playback?

Hi Dale, could you please check what is broken in Chrome such that it can not play a 6-channel file to internal speaker?
Normally it should down-mix the 6-channel audio into 2-channel audio.
But it shows decode error when it tries to play.

50.0.2661.16/7978.7.0 -> good
50.0.2661.57/7978.36.0 -> bad

There were a lot of changes related to media between these two builds
https://chromium.googlesource.com/chromium/src/+log/50.0.2661.16..50.0.2661.57?pretty=fuller&n=10000

Thanks!

https://chromium.googlesource.com/chromium/src/+/8c2780f4c3ffb9bcae756e9d8e761bd85bf9c4b6 is the most likely culprit; though I'm surprised since that should only affect AAC. I can't dig in today but will take a look tomorrow.

+tguilbert who's looking into some security bug fixes around this change too. We may need to revert this change from M50 if the problems can't be resolved easily.

For this specific file, the culprit is definitively the CR that Dale linked to.

There is a mismatch in between the codec_context_ layout and the config layout (CHANNEL_LAYOUT_5_1 versus CHANNEL_LAYOUT_5_1_BACK). This causes this condition to fail https://code.google.com/p/chromium/codesearch#chromium/src/media/filters/ffmpeg_audio_decoder.cc&q=ffmpeg%20audio%20decoder&sq=package:chromium&type=cs&l=304
and FfmpefAudioDecoder thinks there is an unsupported config change.

I am looking into how to fix this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/43eed5f900264ff88be25806c883dab2011260fa

commit 43eed5f900264ff88be25806c883dab2011260fa
Author: tguilbert <tguilbert@chromium.org>
Date: Thu Apr 07 23:34:48 2016

Fixing AudioBuffer params and channel layout bugs

Work for AAC implicit signaling introduced the possiblity for audio rendering
configs to change to change midstream. Checking for channel layout changes
caused a regression and caused 6 channel audio playback to fail.

Clusterfuzz also detected some heap buffer overflow issues, when the decoded
audio buffers we receive have a different channel layout or sample rate than
the ones we expect.

This change allows FfmpegAudioDecoder to ignore channel layout changes on non
AAC codec. It also checks that decoded AudioBuffer sample rate and channel
count match the expected parameters before adding them to the splicer queue, in
AudioRendererImpl.

BUG= 599625 ,  599846 ,  600538 
TEST=manual tests on an ASAN build, with ffmpeg_regression_test to follow
REVIEW=dalecurtis

Review URL: https://codereview.chromium.org/1868983004

Cr-Commit-Position: refs/heads/master@{#385922}

[modify] https://crrev.com/43eed5f900264ff88be25806c883dab2011260fa/media/filters/ffmpeg_audio_decoder.cc
[modify] https://crrev.com/43eed5f900264ff88be25806c883dab2011260fa/media/renderers/audio_renderer_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7f2efb0b0cde7dffa231f43418eeddf9ef897ecc

commit 7f2efb0b0cde7dffa231f43418eeddf9ef897ecc
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Apr 08 19:35:09 2016

Merge M50: "Fixing AudioBuffer params and channel layout bugs"

Work for AAC implicit signaling introduced the possiblity for audio rendering
configs to change to change midstream. Checking for channel layout changes
caused a regression and caused 6 channel audio playback to fail.

Clusterfuzz also detected some heap buffer overflow issues, when the decoded
audio buffers we receive have a different channel layout or sample rate than
the ones we expect.

This change allows FfmpegAudioDecoder to ignore channel layout changes on non
AAC codec. It also checks that decoded AudioBuffer sample rate and channel
count match the expected parameters before adding them to the splicer queue, in
AudioRendererImpl.

BUG= 599625 ,  599846 ,  600538 
TEST=manual tests on an ASAN build, with ffmpeg_regression_test to follow
REVIEW=dalecurtis

Review URL: https://codereview.chromium.org/1868983004

Cr-Commit-Position: refs/heads/master@{#385922}
(cherry picked from commit 43eed5f900264ff88be25806c883dab2011260fa)

Review URL: https://codereview.chromium.org/1870113003 .

Cr-Commit-Position: refs/branch-heads/2661@{#533}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/7f2efb0b0cde7dffa231f43418eeddf9ef897ecc/media/filters/ffmpeg_audio_decoder.cc
[modify] https://crrev.com/7f2efb0b0cde7dffa231f43418eeddf9ef897ecc/media/renderers/audio_renderer_impl.cc

Verified on 7978.57.0, 50.0.2661.79.