1116040 - The dial tone of first digits are much more quiet after the user hangs up a call

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Dialer, defect, P2)

Description

[sync-1]

FFOS2.0 baseline BuildID: 20140916000205	
 
  DEFECT DESCRIPTION:
  The dial tone of frist few numbers very small after user hang up a call.
 
  REPRODUCING PROCEDURES:
  1. Eatablish a call,after the call connected, hang up the call
  2. Dail several numbers in keypad
  3. The dial tone of first few numbers very small（KO）
  
  EXPECTED BEHAVIOUR:
  The dial tone should be loud enough.
  
  Reference mobile's behavior:
  It is OK on Fire E 1.3
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
  100%
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Lingling Zhao]

In fact, the sound comes from receiver in the first seconds.

Wesly, can you please help to trace this bug?
Thanks.

Comment 2

[Lingling Zhao]

[Blocking Requested - why for this release]:The actions related with audio become abnormal after call ended

Comment 3

[Lingling Zhao]

In our analysis, this issue is caused by 1016277. 
In order to fix the bug described in 1016277, AudioCompetingHelper is added to callscreen, if we delete the corresponding code about AudioCompetingHelper, then the issue can not be reproduced.

Comment 4

[Shine(Leave from Mozilla)]

Attachment: Flame2.1 logcat

The bug can be repro on latest Flame 2.1/2.2.
See attachments: Flame2.1_logcat_1454.txt & Video.MP4 & Flame2.2_logcat_1445.txt
Reproducing rate: 100%

Flame 2.1 build:
Gaia-Rev        73be51f998031f06db0cd660c0e388fa621c9f4c
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ea426e47bfc4
Build-ID        20141228001253
Version         34.0

Flame 2.2 build:
Gaia-Rev        3554ea9504046646b4679e3a61317c49fc55ca87
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/67c42c076393
Build-ID        20141228010205
Version         37.0a1

Comment 5

[Shine(Leave from Mozilla)]

Attachment: Flame2.2 logcat

Comment 6

[Shine(Leave from Mozilla)]

Attachment: Video

Comment 7

[Wesly Huang (EPM)]

[Blocking Requested - why for this release]:

[Triage] de-tag given current 2.0 timing, however indeed bothering end user and reproducible in 2.1/2.1 so nom to 2.1 for consideration.

Comment 8

[Lingling Zhao]

Wesly,

Do you know who is responsible for this bug and let him know it?

Comment 9

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Is this a cert blocker?

Comment 10

[Johan Lorenzo [:jlorenzo]]

Gabriele, do you think this is related to bug 834530?

Comment 11

[Jack Liu]

[Blocking Requested - why for this release]:

Hi Wesly,

It seriously affects UE although it's not a cert blocker.

As mentioned in comment#3 by Zhaolingling, I think must do some workaround in patch for bug#1016277.

Thanks.

Comment 12

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Triage: This is a bug that we want it to be fixed but per definition[1] it's not a release blocker.
Does anyone want to take this and contribute?

[1] https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

Comment 13

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Doug, Gabrielle, 
Any clue you see here?

Comment 14

[Wesly Huang (EPM)]

Aligned w/ EPM, considering the symptom, Triage guideline, and 2.0 timing, so far won't set it as branch blocker. In the mean time we'll looking for relative engineer team's view to see if any suggestion can provide for partner.

Comment 16

[Doug Sherk (:drs) (inactive)]

I think this is related to bug 834530 or one of its followups/dependencies. If this is correct, then the fix is probably not trivial. Since I'm not certain of this, I'm just going to set it as a "See Also".

On a side note, I disagree that this is a serious impediment to UE. However, it's a big enough problem that we will prioritize it internally within the Dialer team.

Gabriele can provide more info/analysis.

Comment 17

[Gabriele Svelto [:gsvelto] (PTO)]

I don't think this was caused directly by bug 834530 but my changes there might have made it more apparent.

My analysis is the following: when playing tones the app relies on gecko - and in part to the system app - to send audio to the appropriate channel. The audio channel being used depends on a number of factors: the channel specified when creating an AudioContext, the type of context (e.g. the telephony channel has priority over others) as well as which app is currently active/visible. When we switch around apps such as in this bug the system app will inform gecko about visibility changes and the audio channel management logic will switch audio channels accordingly. Since this process is rather roundabout it can take a while and one might hear sounds from an app being delivered to the wrong channel until the channel is finally adjusted.

The best solution here would be to allow the dialer to use the regular notification channel instead of the media one but to do so we need to fix bug 1092346. In the meantime there's nothing we can do in the dialer to solve this issue without breaking the volume fixes I landed in bug 834530.

Comment 18

[Wesly Huang (EPM)]

Thanks Doug and Gabriele! 

If we have bug 1092346 and this one get fixed (assume 2.2 since this is what 1092364 aiming for) do you think the fix can be easily re-based for 2.0? (meaning done by OEM)

Comment 19

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Wesly Huang from comment #18)
> If we have bug 1092346 and this one get fixed (assume 2.2 since this is what
> 1092364 aiming for) do you think the fix can be easily re-based for 2.0?
> (meaning done by OEM)

No unless they also take bug 834530. Note that bug 834530 wasn't approved for landing on 2.0 but there is a working patch there. I don't know if the vendors have actually taken it or not though; the only thing I'm sure is that it's not in our 2.0 branch nor in 2.0m (IIRC).

Comment 20

[Doug Sherk (:drs) (inactive)]

To fix this properly, we would first need to uplift bug 834530. This patch set is massive and we agreed in the past that we shouldn't uplift it to 2.0m.

Once that's uplifted, we'd also have to fix bug 1092364, which is not a trivial fix, and requires significant investigation to determine what's going on.

As I mentioned in comment 16, I don't think that this is actually that bad of a usability issue, and it's not worth the uplift risk and development cost.

Comment 21

[Wesly Huang (EPM)]

Thanks Doug and Gabriele! Just to shortly summarize:

To fix this issue OEM need to take:

1. the fix of bug 1092346
2. a working patch of bug 834530 (not landed, but working patch exists)
3. (?) do they also need the fix of bug 1092364? (comment#20, maybe a typo?)

Doug, would you help confirm my bullet#3 above?

Comment 22

[Doug Sherk (:drs) (inactive)]

(In reply to Wesly Huang from comment #21)
> 3. (?) do they also need the fix of bug 1092364? (comment#20, maybe a typo?)

Yeah, that was a typo. I meant bug 1092346.

Comment 23

[Wesly Huang (EPM)]

Thanks Doug!

So update here, to fix this issue OEM need to take:

1. the fix of bug 1092346
2. a working patch of bug 834530 (not landed, but working patch exists)

Comment 25

[Josh Cheng [:josh]]

Hi Wesly,
I saw https://bugzilla.mozilla.org/show_bug.cgi?id=834530#c117 and it make strong justification that this bug cannot be fix on 2.0 otherwise it causes more serious issue. Am I correct?

Comment 26

[Wesly Huang (EPM)]

Sorry for late, Josh. I think you are right, even bug 834530 is fixed now but per latest comment (comment 132 as of today) it cause other side effect.

Comment 28

[BMO Automation]

Firefox OS is not being worked on