Touch Tone audio plays at inconsistent, quieter volume after entering Task Manager

RESOLVED FIXED in Firefox 43

Status

()

Core
Audio/Video: MediaStreamGraph
P3
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Marty, Assigned: roc)

Tracking

({regression})

unspecified
mozilla44
ARM
Gonk (Firefox OS)
regression
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.5+, firefox42 unaffected, firefox43+ fixed, firefox44+ fixed, b2g-v2.2 unaffected, b2g-master affected)

Details

(Whiteboard: [2.5-Daily-Testing][Spark], URL)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8675151 [details]
logcat_touch-tone-volume.txt

Description:
If the user returns to Dialer from Task Manager, the Touch Tone audio will often play at a quieter volume.  This lower volume seems to persist until the app is actually closed and reopened.

Repro Steps:
1) Update a Aries to 20151016122951
2) Launch the Dialer app and press several numbers on the keypad
3) Long press the Home button to bring up the task manager
4) Return to the Dialer app and press several more numbers on the keypad

Actual:
Touch Tone volume is consistent every time it is heard.

Expected:
Touch Tone volume is inconsistent after using Task Manager

Environmental Variables:
Device: Aries 2.5
Build ID: 20151016122951
Gaia: 8999f0ba6326d815c8366e3c1155b7e4e9763b40
Gecko: ccf288f658211b6cfab33c458aaf033baed2375b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Repro frequency: 8/8
See attached: Video (URL), Logcat
(Reporter)

Comment 1

2 years ago
Correction, I mistakenly switched the Actual and Expected results in the original post. It should read as such:

Actual Results:
Touch Tone volume is inconsistent after using Task Manager

Expected Results:
Touch Tone volume is consistent every time it is heard.

*************************************

This issue DOES occur on the latest Flame 2.5 build.
Touch Tone volume is inconsistent after using Task Manager

Environmental Variables:
Device: Flame 2.5
BuildID: 20151016030225
Gaia: 8ea9029190af2ffeb04dcd97b323738125e31a0e
Gecko: d374d16cbb251c9dac5af69f8e186e821ce82fe2
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

*************************************

This issue does NOT occur on Flame 2.2
Touch Tone volume is consistent every time it is heard.

Environmental Variables:
Device: Flame 2.2
BuildID: 20151006032504
Gaia: 5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583
Gecko: fc588eb28eab
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]:

Sound volumes should remain consistent. This is a regression. Let's get a window here.
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng
Note: Bug 1201133 exhibits on my last working and first broken. I was able to work around that so it's not too much of a problem.

Last Working
Device: Flame 2.5
BuildID: 20150916161623
Gaia: db6664f0e07e9966283d30cfc7006151fe7103ff
Gecko: b37c36475cd2c7504a29c5fc99c42a8dda99375c
Version: 43.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

First Broken
Device: Flame 2.5
BuildID: 20150916163221
Gaia: db6664f0e07e9966283d30cfc7006151fe7103ff
Gecko: 052e47bcd8ac132b46454bcf81877cf717b7d99f
Version: 43.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b37c36475cd2c7504a29c5fc99c42a8dda99375c&tochange=052e47bcd8ac132b46454bcf81877cf717b7d99f

This issue appears to have been caused by changes made in bug 1189506.
Blocks: 1189506
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: regressionwindow-wanted
Robert this issue seems to have been caused by the changes for bug 1189506.  Can you please take a look?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(roc)
Component: Gaia::System::Window Mgmt → Audio/Video: MSG/cubeb/GMP
Product: Firefox OS → Core
Now that is odd!
Assignee: nobody → roc
Flags: needinfo?(roc)
Fortunately I can reproduce this on my Flame.
Blocking for 2.5 with P3 priority.
blocking-b2g: 2.5? → 2.5+
Priority: -- → P3
The problem seems to be http://hg.mozilla.org/integration/mozilla-inbound/rev/2624ea64e7ab.
Apparently the problem is related to changing the AudioDestinationNode::SetIsOnlyNodeForContext from using blocking to using Suspend.
Created attachment 8677839 [details]
MozReview Request: Bug 1215699. Ensure that AudioGraphDriver uses the MediaStreamGraph's AudioChannel. r=padenot

Bug 1215699. Ensure that AudioGraphDriver uses the MediaStreamGraph's AudioChannel. r=padenot
Attachment #8677839 - Flags: review?(padenot)
The problem is that my changes caused the graph driver to be stopped and a new AudioGraphDriver created (not sure why, but this is probably a good thing). And that triggered a latent bug where recreating the AudioGraphDriver used the default AudioChannel instead of the correct one.

This patch should go onto as many branches as possible since the bug has been around a while and could affect other things.
Comment on attachment 8677839 [details]
MozReview Request: Bug 1215699. Ensure that AudioGraphDriver uses the MediaStreamGraph's AudioChannel. r=padenot

https://reviewboard.mozilla.org/r/23033/#review20583
Attachment #8677839 - Flags: review?(padenot) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/f5ed98fdc16eb2395b41f5a3f5d91076e4705fc0
Bug 1215699. Ensure that AudioGraphDriver uses the MediaStreamGraph's AudioChannel. r=padenot

Comment 13

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b6bf653873b5
FYI, this bug got accidentally backed out and relanded as https://hg.mozilla.org/integration/mozilla-inbound/rev/b6bf653873b5

Comment 15

2 years ago
Backout:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a59b9742c81e
https://hg.mozilla.org/mozilla-central/rev/b6bf653873b5
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Comment on attachment 8677839 [details]
MozReview Request: Bug 1215699. Ensure that AudioGraphDriver uses the MediaStreamGraph's AudioChannel. r=padenot

Approval Request Comment
[Feature/regressing bug #]: 1189506
[User impact if declined]: unexpected volume changes in some situations
[Describe test coverage new/current, TreeHerder]: ?
[Risks and why]: very low-risk patch
[String/UUID change made/needed]: none
Attachment #8677839 - Flags: approval-mozilla-aurora?
Regression from bug 1189506 (landed in 43), tracking for 43+.
status-firefox42: --- → unaffected
status-firefox43: --- → affected
tracking-firefox43: --- → +
tracking-firefox44: --- → +
Comment on attachment 8677839 [details]
MozReview Request: Bug 1215699. Ensure that AudioGraphDriver uses the MediaStreamGraph's AudioChannel. r=padenot

Minor fix for regression from 43. Approved for uplift to aurora.
Attachment #8677839 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/161dd1563f9f
status-firefox43: affected → fixed
You need to log in before you can comment on or make changes to this bug.