Enable implicit signalling for HE AAC v1 & v2 in ADTS.

media/renderers/audio_renderer_impl.cc

Index: media/renderers/audio_renderer_impl.cc
diff --git a/media/renderers/audio_renderer_impl.cc b/media/renderers/audio_renderer_impl.cc
index 0576e02f7ecadff2f44d70432634170c746bdfa8..160e1875e5cfed546fdc08a4bc7cb4712101a622 100644
--- a/media/renderers/audio_renderer_impl.cc
+++ b/media/renderers/audio_renderer_impl.cc
@@ -60,6 +60,7 @@ AudioRendererImpl::AudioRendererImpl(
       media_log_(media_log),
       tick_clock_(new base::DefaultTickClock()),
       last_audio_memory_usage_(0),
+      last_decoded_sample_rate_(0),
       playback_rate_(0.0),
       state_(kUninitialized),
       buffering_state_(BUFFERING_HAVE_NOTHING),
@@ -385,12 +386,51 @@ void AudioRendererImpl::Initialize(
     }
 #endif
 
+    int stream_channel_count = ChannelLayoutToChannelCount(stream->audio_decoder_config().channel_layout());
+    int fiveptone_channel_count = ChannelLayoutToChannelCount(CHANNEL_LAYOUT_5_1);
+
+    // The layout we pass to |audio_parameters_| will be used for the lifetime
+    // of this audio renderer, regardless of changes to hardware and/or stream
+    // properties. Below we choose the max of stream layout vs. hardware layout
+    // to leave room for changes to the hardware and/or stream (i.e. avoid
+    // premature down-mixing).
+    // If stream_channels < hw_channels:
+    //   Taking max means we up-mix to hardware layout. If stream later changes
+    //   to have more channels, we aren't locked into down-mixing to the
+    //   initial layout.
+    // If stream_channels > hw_channels:
+    //   We choose to output stream's layout, meaning mixing is a no-op for the
+    //   renderer. Browser-side will down-mix to the hardware config. If the
+    //   hardware later changes to equal stream channels, browser-side will stop
+    //   down-mixing and use the data from all stream channels.
+    ChannelLayout renderer_channel_layout = CHANNEL_LAYOUT_NONE;
+
+// WORRY: IF STREAM CHANGES, WHERE DOES MIXER LEARN OF THE NEW INPUT CHANNEL COUNT?

[chcunningham, 2016/03/17 21:48:19]

This happens in AudioBufferConverter::AddBuffer. Each time we add a buffer the
buffer's configuration is evaluated against the existing config. If things
change, it makes a new internal AudioConverter with the new input parameters.

+// WORRY: WHERE IS BROWSER LEARNING OF NEW HW CHANNEL COUNT IF SOMETHING GETS PLUGGED IN? WHERE IS BROWSER-SIDE MIXER?

[chcunningham, 2016/03/17 21:48:19]

The HW channel count is updated via audio_device_listener_{mac|win}.cc. We're
missing this feature on linux, so I filed http://crbug.com/595877

The browser-side mixing is done in the AudioConverter held by
OnMoreDataConverter. When the HW changes are detected,
AudioOutputController::OnDeviceChange() will be called, creating a new stream
with the updated configuration making its way to a new OnMoreDataConverter.

+// TODO ABOVE: ADD CRBUGS TO COMMENT. ADD TODO FOR TO BE ABLE TO CHANGE LAYOUTS ON FLY
+// TODO BELOW: TRY USING INTERMEDIATE hw_layout = discrete ? 5.1 : hw_params TO SIMPLIFY CODE.
+
+
+    // We don't know how to mix for DISCRETE layouts (fancy multichannel
+    // hardware). Instead we choose the max of 5.1 and the stream layout with
+    // the hope that the OS will know best how to up-mix to the DISCRETE layout.
+    // Choosing the max avoids pre-maturely down-mixing.
+    if (hw_params.channel_layout() == CHANNEL_LAYOUT_DISCRETE) {

[DaleCurtis, 2016/03/18 00:16:23]

Why not just always use the discrete layout in this case?

[chcunningham, 2016/03/25 01:41:16]

We chatted - thing is we aren't confident that we can properly do the mixing for
discrete. Hoping the OS can umpix us from 5.1 to whatever the fancy layout
happens to be. 

NOTE TO SELF: ping the old bug and see that folks aren't regressed.

+      renderer_channel_layout = stream_channel_count < fiveptone_channel_count ?
+          CHANNEL_LAYOUT_5_1 : stream->audio_decoder_config().channel_layout();
+    } else {
+      // For all non-discrete layouts we know how to up-mix to the hardware
+      // layout. Using the max of stream and hardware channel counts  avoids
+      // premature down-mixing should either the stream or hardware later change
+      // to have more channels.
+      renderer_channel_layout = stream_channel_count < ChannelLayoutToChannelCount(hw_params.channel_layout()) ?
+          hw_params.channel_layout() : stream->audio_decoder_config().channel_layout();
+    }
+
     audio_parameters_.Reset(
         hw_params.format(),
-        // Always use the source's channel layout to avoid premature downmixing
-        // (http://crbug.com/379288), platform specific issues around channel
-        // layouts (http://crbug.com/266674), and unnecessary upmixing overhead.
-        stream->audio_decoder_config().channel_layout(), sample_rate,
+        renderer_channel_layout,
+        sample_rate,
         hw_params.bits_per_sample(),
         AudioHardwareConfig::GetHighLatencyBufferSize(sample_rate,
                                                       preferred_buffer_size));
@@ -490,6 +530,15 @@ void AudioRendererImpl::DecodedAudioReady(
   }
 
   if (expecting_config_changes_) {
+    if (buffer->sample_rate() != last_decoded_sample_rate_) {
+      DVLOG(1) << __FUNCTION__ << " Updating audio sample_rate."
+               << " ts:" << buffer->timestamp().InMicroseconds()
+               << " old:" << last_decoded_sample_rate_
+               << " new:" << buffer->sample_rate();
+      OnConfigChange();
+    }
+    last_decoded_sample_rate_ = buffer->sample_rate();
+
     DCHECK(buffer_converter_);
     buffer_converter_->AddInput(buffer);
     while (buffer_converter_->HasNextBuffer()) {