Multiple tabs in background playing "fake" audio |
||||||||
Issue descriptionWe've recently enabled slow reports from situations where background renderer main thread task load (wall time) is >50% within a one-second interval (Android). I've occasionally seen traces where a tab is seemingly playing audio in the background. They typically run some media tasks posted from DoRead in media/base/fake_audio_worker.cc. I'm not entirely sure what "Fake" in the "FakeAudioWorker" means - maybe the audio is muted, e.g. because Chrome itself is in the background? Or maybe it's always a fake worker on android? In the attached trace, however, there are multiple tabs seemingly playing audio at the same time. At the same time, they regularly execute tasks posted from CheckTranslateStatus in components/translate/content/renderer/translate_helper.cc. Can audio playback be related to this? How do all tabs play audio at the same time? :) For scheduler: Depending on answers to the above, there might be some opportunities for throttling.
,
Jun 29 2018
This generally gets injected if a page creates and never suspends an AudioContext, see issue 732450 .
,
Jun 29 2018
It essentially closes an OS high-power usage stream in favor of a null sink which exists only in the renderer process since the WebAudio spec has no automatic stop for contexts.
,
Jul 10
See also bug 862125 which may be related.
,
Jul 23
,
Jul 23
+WebAudio folks. It's probably worth considering an intervention around shutting down unused contexts.
,
Aug 6
What is an unused context? A context with nothing attached to it? A context with things attached but all source nodes are producing silence?
,
Aug 6
I meant any context which ends up suspended by silent sink suspender, so 30+ seconds of silence. For an intervention, we'd probably want something a little longer 1min+ and some sort of event to occur when the context is suspended so that clients may resume it if needed. Possibly even a unused warning event they can reply to in order to avoid suspension.
,
Aug 6
Oh, ok. Seems reasonable. But there's currently no way for the context to inform the user that it's been suspended (other than the user polling the state of the context). Adding some event for this seems reasonable, but would require a change in the spec. Contexts are supposed to be in the running state until the user suspends it or closes it.
,
Aug 15
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by mlamouri@chromium.org
, Jun 29 2018