Moved from email discussion:

The WIP CL: https://codereview.chromium.org/2916733002/ will SuspendMediaSessions for  issue 716066 . It is like calling pause() on all audio outputs of all Webcontents. However, for the case in  issue 716066 , there will be a short glitch of media sounds.

Dylan comments: "Normal stream playback behavior is chrome sending a bunch of samples to cras, then removing the stream. After the stream is removed, crash finishes playing all the samples from that stream, normally 20-40 ms worth. On suspend, cras will shut down all the devices, but leave the streams. Then on resume it will continue playback of the streams. This was added so chrome didn't have to deal with suspend/resume in the audio path. Now that chrome is dealing with suspend/resume in its audio path we might want to reconsider that decision."

Based on the discussion from engineers involved, we have:

Solution 1: chrome side provides an option to drop the remaining samples when removing the stream if chrome doesn't want the stream to finish playing, like chrome receives the notification of suspend imminent.
Solution 2: CRAS side dumps queued samples across suspend/resume. Some amount of audio would be lost, but might be ok for users. This could be done by SetSuspendAudio call.

Solution 1 & 2 probably should be considered together, depends on whether chrome drops samples when it pauses the stream.

Solution 3: SetAudioMuted(true) before SuspendImminent and SetAudioMuted(false) after SuspendDone. This will make the resumed sample unnoticeable to user. However, IsAudioMuted() could be a user setting, we should respect that.

Daniel's comment for solution 3: make sure we are not in a bad state if Chrome crashes after we set audio muted globally and before ask it unmuted.

Solution 3 might be the quickest engineer effort for this problem, considering in either case last audio samples before suspend are "lost" for users. But it doesn't fix the root cause. I am not sure which direction we should go forward.