Closed Bug 1104646 Opened 9 years ago Closed 9 years ago

Release AudioContext when the keyboard is not visible


(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Not set


(blocking-b2g:2.2+, b2g-v2.2 fixed)

2.2 S1 (5dec)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- fixed


(Reporter: timdream, Assigned: timdream)



(Keywords: regression)


(1 file)

So according to Randy on dev-b2g, the impl in bug 1103574 should not hold a long-lived audio context, or it would cause power consumption problem.

Given the precedent (bug 1079810) was marked as a blocker, this one should be marked as well.
Even if we don't hold an AudioContext when the keyboard is not shown, we would need to be able to do AudioContext#decodeAudioData() when the keyboard is being launched in background. Upon checking MDN I think I should be able to use OfflineAudioContext#decodeAudioData() and not activating the hardware.

Randy, is the above consideration true? Creating an OfflineAudioContext instance shouldn't cause power consumption problem right?
Flags: needinfo?(rlin)
Hi Tim, 
I think Paul is the best guy to answer your question.

Hi Paul, 
Could you explain it?
Flags: needinfo?(rlin) → needinfo?(padenot)
Creating an OfflineAudioContext is cheap in terms of CPU, as long as you don't call startRendering on it.

You can certainly call decodeAudioData() on an OfflineAudioContext. Simply make sure to create your OfflineAudioContext with a sample rate that matches the sample rate of the device. You can find the sample rate of the device using a normal AudioContext and looking at the `sampleRate` property. Having the same sample rate everywhere will minimize the CPU usage when playing the click sounds back.

Again, I'm working on an API to "suspend" an AudioContext, to save battery. I have not started, but the work will happen in bug 1094764.
Flags: needinfo?(padenot)
(In reply to Paul Adenot (:padenot) from comment #3)

Thanks! Submit a patch soon ...
Comment on attachment 8529637 [details] [review]
mozilla-b2g:master PR#26522

The state is controlled by StateManager, therefore this patch makes StateManager explicitly activate/deactivate FeedbackManager, which activate/deactivate SoundFeedbackManager & SoundFeedbackPlayer.

A simpler patch would be have the SoundFeedbackPlayer listens to visibilitychange event, but I don't think it's the right way.
Attachment #8529637 - Flags: review?(jlu)
Comment on attachment 8529637 [details] [review]
mozilla-b2g:master PR#26522

Looks pretty good. Nice job!
Attachment #8529637 - Flags: review?(jlu) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S1 (5dec)
2.2+ all fixed regressions -- reset if disagree.
blocking-b2g: 2.2? → 2.2+
You need to log in before you can comment on or make changes to this bug.