Using the Audio Data API on otoro slow down the device

RESOLVED FIXED in mozilla17

Status

()

Core
Audio/Video
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: vingtetun, Assigned: cpearce)

Tracking

({perf})

Trunk
mozilla17
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(2 attachments)

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
(Assignee)

Comment 1

5 years ago
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

Comment 2

5 years ago
The Gaia dialer app uses the Audio Data API (mozWriteAudio) to generate the tones.
(Assignee)

Updated

5 years ago
Summary: Using the Audio API on otoro slow down the device → Using the Audio Data API on otoro slow down the device
(Assignee)

Comment 3

5 years ago
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
(Assignee)

Comment 7

5 years ago
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.

Comment 8

5 years ago
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.
(Assignee)

Comment 10

5 years ago
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.
(Assignee)

Comment 11

5 years ago
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.
(Assignee)

Comment 12

5 years ago
Created attachment 653641 [details] [diff] [review]
Patch: reset mAudioStream in nsHTMLMediaElement::AbortExistingLoads()
Attachment #653641 - Flags: review?(chris.double)

Updated

5 years ago
Attachment #653641 - Flags: review?(chris.double) → review+
(Assignee)

Comment 13

5 years ago
Gaia pull request:
https://github.com/mozilla-b2g/gaia/pull/3623
(Assignee)

Comment 14

5 years ago
Created attachment 653653 [details] [diff] [review]
Patch 2: Remove redundant mAudioStream reset

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+
(Assignee)

Comment 15

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/028c2346c777
https://hg.mozilla.org/integration/mozilla-inbound/rev/e45223cbd1c4
https://hg.mozilla.org/mozilla-central/rev/028c2346c777
https://hg.mozilla.org/mozilla-central/rev/e45223cbd1c4
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.