Closed Bug 779914 Opened 7 years ago Closed 7 years ago

Using the Audio Data API on otoro slow down the device

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla17
blocking-basecamp +

People

(Reporter: vingtetun, Assigned: cpearce)

Details

(Keywords: perf)

Attachments

(2 files)

Steps to reproduce:
 - Have an otoro device with Gaia on it
 - pan the homescreen and see how fast it is
 - launch the dialer application and hit one of the number key, it should play a sound with the Audio API.
 - Hit the home key to go back to the homescreen 
 - pan again

Actual result:
 - The homescreen is really slow down

Expected result:
 - The homescreen speed has not changed
blocking-basecamp: --- → +
Keywords: perf
Just to be clear, you're referring to the HTML5 <audio> API, not the Audio Data API which enables you to play raw samples?
Component: DOM: Core & HTML → Video/Audio
The Gaia dialer app uses the Audio Data API (mozWriteAudio) to generate the tones.
Summary: Using the Audio API on otoro slow down the device → Using the Audio Data API on otoro slow down the device
Presumably the Gaia developer's chose to use the Audio Data API rather than the standard <audio> elements because <audio> has too high latency?

Can we use the new media streams API instead to work around this issue?
Does this disappear after some time (i.e., when a GC happens)?  How about if you force the audio stream to close by doing an null load (audioelement.src = null) when navigating away from the dialer?
Yeah, once the tone has finished we should do something to ensure callbacks are no longer being fired.
Chris, who should own this?  What needs to do something, the web page or Gecko?
Assignee: nobody → cpearce
I can own this for now. I'm not sure if we should work around this in Gaia for the time being, or fix it in Gecko, but I can either of those things.
Andrew, given the million Chris' that work for Mozilla, two of which actively commenting in this bug, can you be more specific about which Chris you're asking for a response from?
(In reply to Chris Double (:doublec) from comment #8)
> Andrew, given the million Chris' that work for Mozilla, two of which
> actively commenting in this bug, can you be more specific about which Chris
> you're asking for a response from?

Will do.  In this case I assigned it to Chris Pearce at the same time so I thought it was clear.
Since we're planning to implement the Web Audio API and move away from the Audio Data API I don't think it's worth us spending time fixing the Audio Data API; I think we should just work around this issue.

If we shutdown the audio stream when the dialer app goes into the background, and recreate it if/when the dialer app is brought back to the forefront, the problem goes away.

So I propose we make the following changes to work around this problem:
* Change nsHTMLMediaElement::AbortExistingLoads() to shutdown and reset mAudioStream if it's non-null. Then setting HTMLMediaElement.src=""; will cause the Audio Data API to be reset.
* Change the Gaia dialer app to reset/recreate the audio stream (_audio.src=null;delete _audio;) in a mozvisibilitychange event handler, and recreate it in the same handler if !document.mozHidden.

Something like:


I'll prepare a patch an a pull request to make these changes.
Bah, there was a failure somewhere between my brain the my keyboard. What I meant to say was:

Since we're planning to implement the Web Audio API and move away from the Audio Data API I don't think it's worth us spending time fixing the Audio Data API; I think we should just work around this issue.

If we shutdown the audio stream when the dialer app goes into the background, and recreate it if/when the dialer app is brought back to the forefront, the problem goes away.

So I propose we make the following changes to work around this problem:
* Change nsHTMLMediaElement::AbortExistingLoads() to shutdown and reset mAudioStream if it's non-null. Then setting HTMLMediaElement.src=""; will cause the Audio Data API to be reset.
* Change the Gaia dialer app to reset/recreate the audio stream in a mozvisibilitychange event handler, the handler would do something like:

  if (document.mozHidden) {
     this._audio.src = null;
     delete this._audio;
  } else {
     // init audio...
  }

I'll prepare a patch an a pull request to make these changes.
Attachment #653641 - Flags: review?(chris.double) → review+
We also don't need the existing mAudioStream reset in nsHTMLMediaElement::LoadResource() once we reset AbortExistingLoads(), as the AbortExistingLoads() will always run before LoadResource() is called.
Attachment #653653 - Flags: review?(kinetik)
Attachment #653653 - Flags: review?(kinetik) → review+
https://hg.mozilla.org/mozilla-central/rev/028c2346c777
https://hg.mozilla.org/mozilla-central/rev/e45223cbd1c4
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.