Closed Bug 875227 Opened 11 years ago Closed 11 years ago

[Buri][REG][Audio]No call sound when the call established

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:tef+, b2g18 verified, b2g18-v1.0.1 verified)

VERIFIED FIXED
blocking-b2g tef+
Tracking Status
b2g18 --- verified
b2g18-v1.0.1 --- verified

People

(Reporter: sync-1, Assigned: rlin)

References

Details

Attachments

(1 file, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #457520 +++
 
 DEFECT DESCRIPTION:
 [REG][Audio]No call sound when the call established
 
  REPRODUCING PROCEDURES:
 1.make the first call->the call established
 2.the call sound too loud in the earpiece==>KO1.
 3.end the call and make the second call->the call established
 4.listen to the call sound->No call sound in the earpiece==>KO2.
 
  EXPECTED BEHAVIOUR:
 the call sound normally
 
 ASSOCIATE SPECIFICATION:
 TEST PLAN REFERENCE:
 TOOLS AND PLATFORMS USED:
 USER IMPACT:high
 REPRODUCING RATE:5/5
 For FT PR, Please list reference mobile's behavior:
 
 Li Xin
 Tel:(021)61460666-6884
 
 ++++++++++ end of initial bug #457520 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Mozilla build ID:20130514070202
blocking-b2g: --- → tef?
rlin is working on this
Assignee: nobody → rlin
earpiece means receiver
More information:  Earpiece means receiver.

Now, the receiver mode is not working normally.  When making call, need to switch to speaker mode to hear the voice.

KO1 means, the first call,it should be in receiver mode, but actually it is in speaker mode
KO2 means, receiver mode will totally not working after the first call. No sound can be heard.  In this case, switch manually to speaker mode, the sound will come back. But can not switching back anymore.
Attached patch patch v1 (obsolete) — Splinter Review
SWITCH_STATE_OFF = 1, not 0.
During the boot-up state and without headset plug-in, it would run the InternalSetAudioRoutesICS and this bug would cause to remove the earpiece device.
Attachment #753185 - Flags: review?
Attachment #753185 - Flags: review? → review?(mwu)
Attachment #753185 - Flags: review?(mwu) → review?(mchen)
Comment on attachment 753185 [details] [diff] [review]
patch v1

Review of attachment 753185 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/AudioManager.cpp
@@ +52,5 @@
>    15,  // FM
>  };
>  
>  // A bitwise variable for recording what kind of headset is attached.
> +static int sHeadsetState = 0;

1. The previous assignment to SWITCH_STATE_OFF is obviously wrong because it is used for switch state not here. As comment said it is a bitwise variable and use audio_devices_t enum to assign it.

2. The global and static variable is initialized to 0 automatically, so we don't need to do this.
   Is there any other bug caused this change or just to do initialization?
Attached patch patvh v2Splinter Review
Remove the assignment.
Attachment #753185 - Attachment is obsolete: true
Attachment #753185 - Flags: review?(mchen)
Attachment #753206 - Flags: review?(mchen)
Comment on attachment 753206 [details] [diff] [review]
patvh v2

Review of attachment 753206 [details] [diff] [review]:
-----------------------------------------------------------------

I am Ok with it but I didn't be authorized to give approval on this file. So add request to mwu.
Attachment #753206 - Flags: review?(mwu)
Attachment #753206 - Flags: review?(mchen)
Attachment #753206 - Flags: review+
Not a gaia bug, change the component.
Component: Gaia → General
Comment on attachment 753206 [details] [diff] [review]
patvh v2

Review of attachment 753206 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/AudioManager.cpp
@@ +52,5 @@
>    15,  // FM
>  };
>  
>  // A bitwise variable for recording what kind of headset is attached.
> +static int sHeadsetState;

= SWITCH_STATE_ON;
Attachment #753206 - Flags: review?(mwu) → review+
blocking-b2g: tef? → tef+
Thanks Michael for marking it tef+, Can we fix the nits and land this in 1.0.1 asap?
No nits from me. This ok to land. That particular variable is a bitfield so initializing it with zero makes sense.
Can we then just land this? Has QA checked whether this bug affects other devices (strange none realize it earlier)?
It's midnight in Taiwan. Can someone in the US help to land this? Thanks.
Flags: needinfo?
I'll land on inbound.
Flags: needinfo?
(In reply to Michael Wu [:mwu] from comment #16)
> I'll land on inbound.

Thank you, Michael.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
this issue also reproduces on Leo(v1-train) and Inari(v1.0.1) devices

1) receive a call on the Test device - cannot hear any voice
2) turn on speaker mode - cannot turn it off (can hear the voice through the speaker)

Leo build info:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/2f8bf6531f39
Gaia   805ae3df8a50609bf89a659687e473c96b683cd2
Build  2013-05-23-07-02-06
Version 18.0

Inari build info:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/047b7010c99a
Gaia   09299399500b50de72cdd3b4365fc6455bbbb145
Build  2013-05-23-07-02-10
Version 18.0
Keywords: qawanted
Those two version don't include my patches,
b2g18 is 
39c232e1572a
2013-05-23 18:28 +0800	rlin - Bug 875227 - No call sound when the call established, r=mwu a=tef+ default tip 
b2g18 v1.0.1 is 
0cc62659b472
2013-05-23 18:28 +0800	rlin - Bug 875227 - No call sound when the call established, r=mwu a=tef+ default tip
Status: REOPENED → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Hi Ryan,
I checked the mozilla-central and can't found this patch.
Can you help to check?
Flags: needinfo?(ryanvm)
Looks like birch hasn't been merged over to m-c yet. Maybe Ed can help :)
Flags: needinfo?(ryanvm) → needinfo?(emorley)
Merge is waiting on likely releng bustage (have clobber builds going just in case it's our excuse for a build system :-)).
Flags: needinfo?(emorley)
https://hg.mozilla.org/mozilla-central/rev/58f93b25c91d
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
This bug is not longer reproduces on V1.1-train and V1.0.1

Steps and actual result:
1) Make a call to the testing device. 
   A voice can be heard from both parties in receiving mode
2) Turn on the speaker on the testing device
   The voice can be heard on the testing device via speaker
3) Turn off the speaker on the testing device
   The voice can be heard from the receiver
3) Make the second call to the testing device
   When answered,the voice can be heard from both parties

 The testing device is able to receive and send phone calls and switches between the speaker and receiving  mode without issues

Environmental  Variables:
Buri Build ID: 20130530070213
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/11b55d3ada71
Gaia: ac293ce59acc3bede083fad1b973794fa8bf0253

Environmental  Variables:
Unagi Build ID: 20130530070208
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/09ac1fd2959c
Gaia: 1cca9324d4444ad28c6fa99875e17abf7e8230be


Environmental  Variables:
Inari Build ID: 20130530070213
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/11b55d3ada71
Gaia: ac293ce59acc3bede083fad1b973794fa8bf0253
Status: RESOLVED → VERIFIED
Comment from Mozilla:This bug is not longer reproduces on V1.1-train and V1.0.1
 
 Steps and actual result:
 1) Make a call to the testing device. 
    A voice can be heard from both parties in receiving mode
 2) Turn on the speaker on the testing device
    The voice can be heard on the testing device via speaker
 3) Turn off the speaker on the testing device
    The voice can be heard from the receiver
 3) Make the second call to the testing device
    When answered,the voice can be heard from both parties
 
  The testing device is able to receive and send phone calls and switches between the speaker and receiving  mode without issues
 
 Environmental  Variables:
 Buri Build ID: 20130530070213
 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/11b55d3ada71
 Gaia: ac293ce59acc3bede083fad1b973794fa8bf0253
 
 Environmental  Variables:
 Unagi Build ID: 20130530070208
 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/09ac1fd2959c
 Gaia: 1cca9324d4444ad28c6fa99875e17abf7e8230be
 
 
 Environmental  Variables:
 Inari Build ID: 20130530070213
 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/11b55d3ada71
 Gaia: ac293ce59acc3bede083fad1b973794fa8bf0253
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: