CC+=chcunningham@ who is working on some similar paths in desktop.

wolenetz@, chcunningham@, is this a chunk demuxer issue?

I would expect a ConfigChanged access unit from the chunk demuxer when channel count changes

I'd guess this is due to SBR signalling implicit changes. chcunningham@ knows more.

Dale is right, this is likely SBR implicit signaling. In addition to channel config, you may also see sample rate change (perhaps addressed in  issue 443012 ). Let me know if you need help finding sample content to easily demonstrate this.

Looks like we used to have a method to reconfigureAudioTrack [0], but that was removed [1] in favor of a less disruptive patch for changing sample rates. I'm not familiar with AudioTrack, but it seems like we can at least re-create it like we used to in [0]. Perhaps you already have a more surgical plan ;)

[0] https://codereview.chromium.org/813643002/patch/20001/30001
[1] https://codereview.chromium.org/805273007/patch/180001/190003

I tried to provide a quick fix here: https://bugs.chromium.org/p/chromium/issues/detail?id=596683#c3
It is not a good fix, since we may lost pre-existing audio data when recreating a new AudioTrack.

Could you please provide a right fix at chunk_demuxer level? Thanks.

Unfortunately this can't be done in ChunkDemuxer because the signal requires decoded the AAC packet. It is something that decoders must handle. As we switch to the unified media pipeline this will be handled by the bug chris is already working on. This is ultimately  issue 534301 .

For EME in the future, we'll want timav@'s MediaCodecAudioDecoder to support implicit changes.

FYI: this is the change for unified media pipeline. 
https://codereview.chromium.org/1805013003/

Andy will make a faster fix for cast. My change to fix spitzer go out in m51.

Cast team will have a local patch for this issue until we switch to unified media pipeline.