1427937 - audio context should release its wakelock when it's non-audible

Status: NEW

(Core :: Web Audio, enhancement, P2)

Description

[Alastor Wu [:alwu]]

The report from google app team shows that sometime the audio wakelock doesn't be unlocked correctly, and it would cause a power waste.

> org.mozilla.firefox : AudioMix, with partial_wakelock_time 2h47m5.954s

The partial_wakelock is created from here
https://searchfox.org/mozilla-central/rev/b24e6342d744c5a83fab5c15972e11eeb69d68e6/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#560

Comment 1

[Alastor Wu [:alwu]]

After some investigation, I found that 'AudioMix' wakelock is not called by firefox directly, the topics we use for audio/video are 'audio-playing' or 'video-playing'. Not sure where is the 'AudioMix' from.

Ex.  (using firefox to play music) $dumpsys power
Wake Locks: size=2
  PARTIAL_WAKE_LOCK  'AudioMix' ACQ=-1m30s662ms LONG (uid=1041 ws=WorkSource{10128})
  PARTIAL_WAKE_LOCK  'audio-playing' ACQ=-1m30s649ms LONG (uid=10128 pid=20982)

Comment 2

[Alastor Wu [:alwu]]

This issue is caused by web audio. 
When you create an AudioContext, the AudioMix wakelock would exist until it's destroyed.
What I guess is that AudioStream continuely input silent data to audio hardware so that audio server would always keep its wakelock.

---

STR.
1. goto https://alastor0325.github.io/htmltests/non_mse_tests/webaudio_silent.html
2. put the tab on background
3. $ adb shell dumpsys power
4. then you would see the 'AudioMix' wakelock exists until the tab is destoryed

Comment 3

[Alastor Wu [:alwu]]

Hi, Paul,
Since we use an audio driver for AudioContext, the cubeb stream would cause audio backends to request wake lock even web audio's non-audible. (both OSX and Android would do so)

The rough solution might be changing back to system clock driver once we detect the web audio is continuely outputing silent data over a specific time.
Do you have any idea for this issue?
Thanks!

Comment 4

[Paul Adenot (:padenot)]

This is a feature, not a bug.

Application authors that wish to save battery power can call `suspend` or even `close` on the `AudioContext`.

What is this google app report?

Comment 5

[Alastor Wu [:alwu]]

(In reply to Paul Adenot (:padenot) from comment #4)
> This is a feature, not a bug.
> 
> Application authors that wish to save battery power can call `suspend` or
> even `close` on the `AudioContext`.
> 
> What is this google app report?

I would ask them for more details.
BTW, Is this feature defined by spec? or just our feature?
Thanks.

Comment 6

[Paul Adenot (:padenot)]

(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #5)
> I would ask them for more details.
> BTW, Is this feature defined by spec? or just our feature?

This is in the Web Audio API specification [0].

[0]: https://webaudio.github.io/web-audio-api/