1836994 - The AudioIPC Client Callback and GraphRunner threads can wake-up frequently in background tabs

Status: RESOLVED DUPLICATE of bug 1771179

(Core :: Web Audio, defect)

Description

[Florian Quèze [:florian]]

Attachment: Reduced testcase

I noticed that the content process of a Zimbra webmail remained active even when the tab was in the background, and that the AudioIPC Client Callback and GraphRunner threads were waking-up very frequently. I was surprised to see that the process priority is "background", which is a priority we only set when the tab has no Audio.

Digging into the code (the folder is named zx/zimlet/com_zextras_team_classic), I could make a reduced testcase, that I'm attaching.
Profile of the testcase: https://share.firefox.dev/3qsKoLk

I also noticed that the devtools console for the tab contains this message twice: "An AudioContext was prevented from starting automatically. It must be created or resumed after a user gesture on the page."
Once on the new AudioContext() call and once on the oscillator.start() call.

Comment 1

[Paul Adenot (:padenot)]

Another offender, duping against the bug where we want to solve this: 1771179.

Comment 2

[Florian Quèze [:florian]]

(In reply to Paul Adenot (:padenot) from comment #1)

Another offender, duping against the bug where we want to solve this: 1771179.

*** This bug has been marked as a duplicate of bug 1771179 ***

If I understand correctly, bug 1771179 is about stopping streams that have been silent for a while. Here the "An AudioContext was prevented from starting automatically." error message makes me think the streams should not even start. Isn't there something we could do in this case to make the audio threads not start in the first place?

Comment 3

[Paul Adenot (:padenot)]

What you're describing is included in what I planned to do for bug 1771179. It's not always easy to understand, from script, that we can stop expensive real-time audio streams (and their associated threads).

In particular, in your example, it's the presence of a MediaStream (via createMediaStreamDestination, that returns an MediaStreamAudioDestinationNode, that has a stream propertythat's aMediaStream`) that causes what you see. It causes the whole real-time audio machinery to start.

We may want to rename bug 1771179 for "AudioContext power optimizations", because pausing silent context is only part of the solution (but always work -- however we can also implement other things that work faster, without having to wait for a long silence period).

Comment 4

[Karl Tomlinson (:karlt)]

If sites are using createMediaStreamDestination(), then I guess that would be for the purpose of connecting to an HTMLMediaElement, so we should check also that any tracks created by the HTMLMediaElement in such a situation do not wake up the graph.