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)
Tracking
(blocking-b2g:tef+, b2g18 verified, b2g18-v1.0.1 verified)
VERIFIED
FIXED
blocking-b2g | tef+ |
People
(Reporter: sync-1, Assigned: rlin)
References
Details
Attachments
(1 file, 1 obsolete file)
903 bytes,
patch
|
mchen
:
review+
mwu
:
review+
|
Details | Diff | Splinter Review |
+++ 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:
Updated•11 years ago
|
blocking-b2g: --- → tef?
Comment 3•11 years ago
|
||
earpiece means receiver
Comment 4•11 years ago
|
||
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.
Assignee | ||
Comment 5•11 years ago
|
||
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?
Assignee | ||
Updated•11 years ago
|
Attachment #753185 -
Flags: review? → review?(mwu)
Assignee | ||
Updated•11 years ago
|
Attachment #753185 -
Flags: review?(mwu) → review?(mchen)
Comment 6•11 years ago
|
||
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?
Assignee | ||
Comment 7•11 years ago
|
||
Remove the assignment.
Attachment #753185 -
Attachment is obsolete: true
Attachment #753185 -
Flags: review?(mchen)
Attachment #753206 -
Flags: review?(mchen)
Comment 8•11 years ago
|
||
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+
Comment 10•11 years ago
|
||
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;
Updated•11 years ago
|
Attachment #753206 -
Flags: review?(mwu) → review+
Updated•11 years ago
|
blocking-b2g: tef? → tef+
Updated•11 years ago
|
status-b2g18:
--- → affected
status-b2g18-v1.0.1:
--- → affected
Comment 12•11 years ago
|
||
Thanks Michael for marking it tef+, Can we fix the nits and land this in 1.0.1 asap?
Comment 13•11 years ago
|
||
No nits from me. This ok to land. That particular variable is a bitfield so initializing it with zero makes sense.
Comment 14•11 years ago
|
||
Can we then just land this? Has QA checked whether this bug affects other devices (strange none realize it earlier)?
Keywords: checkin-needed,
qawanted
Comment 15•11 years ago
|
||
It's midnight in Taiwan. Can someone in the US help to land this? Thanks.
Flags: needinfo?
Comment 17•11 years ago
|
||
(and by inbound I meant birch) https://hg.mozilla.org/projects/birch/rev/58f93b25c91d
Comment 18•11 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #16) > I'll land on inbound. Thank you, Michael.
Comment 19•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g18/rev/39c232e1572a https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/0cc62659b472
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•11 years ago
|
Keywords: checkin-needed
Comment 20•11 years ago
|
||
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
Assignee | ||
Comment 21•11 years ago
|
||
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
Updated•11 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 22•11 years ago
|
||
Hi Ryan, I checked the mozilla-central and can't found this patch. Can you help to check?
Flags: needinfo?(ryanvm)
Comment 23•11 years ago
|
||
Looks like birch hasn't been merged over to m-c yet. Maybe Ed can help :)
Flags: needinfo?(ryanvm) → needinfo?(emorley)
Comment 24•11 years ago
|
||
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)
Comment 25•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/58f93b25c91d
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Comment 32•11 years ago
|
||
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
Reporter | ||
Comment 33•11 years ago
|
||
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.
Description
•