Current audio stream restart sequence (see RendererImpl::RestartStreamPlayback):
1. Stop ticking the time source and flush the audio renderer.
2. During flush we get a HAVE_NOTHING buffering notification for audio stream. At this point we'll start a deferred audio underflow callback (deferred_audio_restart_underflow_cb_).
3. When flush is done, restart audio renderer (audio_renderer_->StartPlaying). This will cause audio renderer to resume reading from DemuxerStream and decoding audio data. But at this point there's no ready (decoded) audio data for playback yet.
4. Later, when audio renderer gets enough decoded audio data to restart playback and fires HAVE_ENOUGH buffering notification. At this point we'll pause and then restart audio + video playback.

There's two issues that we need to investigate:
1. We might want to call audio_renderer->SetMediaTime in step #2 above (before audio_renderer_->StartPlaying).
2. Also the reason for pausing and then restarting both audio+video in step #4 is that I've seen audio drift (i.e. audio and video become unsynchronized) when playing src=/FFmpeg videos and enabling/disabling audio stream. It's not clear what exactly causes this, although I suspect that this might have something to do with the fact that a. in case of FFmpeg demuxer we have a single read position and so when restarting audio stream we cannot guarantee that audio is available at the current playback position, so audio decoder will only be able to decode after the current FFmpeg demuxer read position.
I'll need to look further into these two issues and see if improvements can be made here.