Closed Bug 1002538 Opened 11 years ago Closed 11 years ago

[B2G][Open_C][Dialer]No sound when making an outbound call from call log or contact

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified)

RESOLVED FIXED
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified

People

(Reporter: astole, Unassigned)

References

Details

(Keywords: regression, smoketest)

Attachments

(1 file)

If a call is made through the call log or contact, no sound can be heard on the device making the call or the device receiving the call. If the call is manually input, then the call functions correctly. Repro Steps: 1) Update a Open_c to BuildID: 20140428040200 2) Have a call in the call log 3) Open dialer app and go to recent calls 4) Tap on the number from step 2 and select call Actual: No sound can be heard from the device making the call or the device receiving the call Expected: Sound can be heard from both devices 2.0 Master Environmental Variables: Device: Open_C 2.0 Master MOZ BuildID: 20140428040200 Gaia: f50d8a3504e0a57d371457c50a6ced333e20724d Gecko: 4d926af89907 Version: 31.0a1 Firmware Version: P821A10-ENG_20140410 Repro frequency: 100% See attached: logcat
Attached file logcat (deleted) —
- The issues only reproduce on Open_C device, does NOT reproduce on Buri master build - The issue does NOT reproduce on aurora Open_C Buri master BuildID: 20140428040200 Gaia: f50d8a3504e0a57d371457c50a6ced333e20724d Gecko: 4d926af89907 Version: 31.0a1 Open_C aurora BuildID: 20140428000206 Gaia: d23e479e8a4ce0bc620acb2d7e2f82801aa4d0ea Gecko: 36f67ce46855 Version: 30.0a2
blocking-b2g: --- → 2.0?
QA Contact: jzimbrick
b2g-inbound Regression Window: Last Working Environmental Variables: Device: Open C BuildID: 20140424233002 Gaia: facd91d31db983a60c7f1035ca01b727c7a1de65 Gecko: d0b5b4a4fc4f Version: 31.0a1 Base Image: P821A10-ENG_20140410 First Broken Environmental Variables: Device: Open C BuildID: 20140425023000 Gaia: c0ccd850287f8c55a23cee91d3e13e23f5b6fa99 Gecko: 384597c65bf1 Version: 31.0a1 Base Image: P821A10-ENG_20140410 Last Working Gaia / First Broken Gecko: Issue DOES occur. Gaia: facd91d31db983a60c7f1035ca01b727c7a1de65 Gecko: 384597c65bf1 First Broken Gaia / Last Working Gecko: Issue does NOT occur. Gaia: c0ccd850287f8c55a23cee91d3e13e23f5b6fa99 Gecko: d0b5b4a4fc4f b2g-inbound Gecko Pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=d0b5b4a4fc4f&tochange=384597c65bf1
Either bug 999334 or bug 984498 caused this. Can you guys find out which bug caused this?
Flags: needinfo?(szchen)
Flags: needinfo?(scheng)
I don't have OpenC device here. Could the issue be reproduce on other device? I have checked tarako (1.3T) and the result is fine (See bug 999334 comment 35).
Flags: needinfo?(szchen)
(In reply to Szu-Yu Chen [:aknow] from comment #5) > I don't have OpenC device here. Could the issue be reproduce on other > device? I have checked tarako (1.3T) and the result is fine (See bug 999334 > comment 35). Tarako isn't related to this bug - this was filed against trunk. This only reproduces on Open C, doesn't reproduce on Buri. I'm adding qawanted to see if we can reproduce with a Flame device.
Keywords: qawanted
Currently blocked from testing this issue on the Flame by (I believe) Bug 1003011. The phone currently does not recognize SIM cards in either slot, so I am unable to place the calls necessary to reproduce this bug. Will recheck when Bug 1003011 is fixed, unless there is a valid work around available to test this right now on the Flame. Environmental Variables: Device: Flame BuildID: 20140429040202 Gaia: 725a23802708eb70e3d7e8a2ce7179adbac806e4 Gecko: d7c07694f339 Version: 32.0a1 Base Image: v10E
Keywords: qaurgent
Keywords: qaurgent, qawanted
I believe you're blocked by : Bug 994463 - [Flame][Build][RIL] After flashing gecko, RIL part doesn't work.
Depends on: 994463
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #8) > I believe you're blocked by : > Bug 994463 - [Flame][Build][RIL] After flashing gecko, RIL part doesn't work. We don't need to mark this as a dependency then - that just means we won't be able to test this on Flame as a point of comparison.
No longer depends on: 994463
I am able to repro this issue on the latest 2.0 Open_C Build. I am unable to hear the phone conversation through either device until turning on Speaker mode on Open_C. 2.0 Environmental Variables: Device: Open_C 2.0 BuildID: 20140429040202 Gaia: 725a23802708eb70e3d7e8a2ce7179adbac806e4 Gecko: d7c07694f339 Version: 32.0a1 Firmware Version: P821A10-ENG_20140410
(In reply to Jason Smith [:jsmith] from comment #9) > (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from > comment #8) > > I believe you're blocked by : > > Bug 994463 - [Flame][Build][RIL] After flashing gecko, RIL part doesn't work. > > We don't need to mark this as a dependency then - that just means we won't > be able to test this on Flame as a point of comparison. I can reproduce on my Flame with yesterday's build. I'll investigate first since Star is working on other higher priority bugs.
Assignee: nobody → echou
Flags: needinfo?(scheng)
blocking-b2g: 2.0? → 2.0+
> > Repro Steps: > 1) Update a Open_c to BuildID: 20140428040200 > 2) Have a call in the call log > 3) Open dialer app and go to recent calls > 4) Tap on the number from step 2 and select call > update: As long as I triggered a keypad sound before creating the second call (for example, go to keypad page and press an '8'), after that even dialing from call log page the call wouldn't be muted.
I have some similar but a bit different behavior on my Nexus S, in bug 1005498
Alexandre's analysis on the related bug (which is likely a dupe of this bug) indicates this is a regression from a change in audio channels, which pretty much nails down bug 984498 as the cause. That patch needs to be backed out.
Blocks: 984498
(In reply to Jason Smith [:jsmith] from comment #14) > Alexandre's analysis on the related bug (which is likely a dupe of this bug) > indicates this is a regression from a change in audio channels, which pretty > much nails down bug 984498 as the cause. > > That patch needs to be backed out. Jason, as far as I can tell, bug 984498 has been backed out hence, this cannot explain the behavior I have been seeing.
(In reply to Alexandre LISSY :gerard-majax from comment #15) > (In reply to Jason Smith [:jsmith] from comment #14) > > Alexandre's analysis on the related bug (which is likely a dupe of this bug) > > indicates this is a regression from a change in audio channels, which pretty > > much nails down bug 984498 as the cause. > > > > That patch needs to be backed out. > > Jason, as far as I can tell, bug 984498 has been backed out hence, this > cannot explain the behavior I have been seeing. That patch hasn't been backed out on trunk.
(In reply to Jason Smith [:jsmith] from comment #16) > (In reply to Alexandre LISSY :gerard-majax from comment #15) > > (In reply to Jason Smith [:jsmith] from comment #14) > > > Alexandre's analysis on the related bug (which is likely a dupe of this bug) > > > indicates this is a regression from a change in audio channels, which pretty > > > much nails down bug 984498 as the cause. > > > > > > That patch needs to be backed out. > > > > Jason, as far as I can tell, bug 984498 has been backed out hence, this > > cannot explain the behavior I have been seeing. > > That patch hasn't been backed out on trunk. Oh you're right, I'm testing with a gecko checkout of ad334fd83f8ce79eeb94d5e6102bbd4345d97f7a, just before those patches landed on master.
As documented on bug 1005498 comment 12, my issue was due to the patch of bug 999334. Looking at bug 999334 comment 36 shows that this one has already been suspected of causing the present issue.
Hmm ok. I'm going to clear the blocking bug here as we need to diagnose what caused this bug specifically as well.
No longer blocks: 984498
(In reply to Natalya Kot [:nkot] from comment #2) > - The issues only reproduce on Open_C device, does NOT reproduce on Buri > master build > - The issue does NOT reproduce on aurora Open_C I question if this is correct. The related bug indicates that this only happens with certain SIMs. Can we retest this on Buri with the same SIM used on the Open C device?
Keywords: qawanted
Update: I just flashed today's build on my Flame and had a more detailed test. Please see test results below: = Step-by-step = ( 1) Full flash ( 2) Launch keypad of Dialer app and make a call => sound can be heard ( 3) Hangup ( 4) Switch to call log. Click on the call just made and select "call" to make a call => no sound ( 5) Hangup ( 6) Switch to call log. Click on the call just made and select "call" to make a call => no sound ( 7) Switch to keypad of Dialer app and press an "8" => A beep can be heard ( 8) Switch to call log. Click on the call just made and select "call" to make a call => no sound (This is different from the previous test. See comment 12) ( 9) Hangup (10) Switch to call log. Click on the call just made and select "call" to make a call => no sound (11) During the call, click the keypad icon to open keypad, press an "8" => A beep can be heard, and the sound is back. (12) Hangup The following observation is really interesting: (13) Switch to call log. Make 3 consecutive calls (Call -> Hangup -> Call -> Hangup -> Call -> Hangup) => Sound can be heard in all 3 calls. (14) Launch keypad of Dialer app and make a call => sound can be heard (15) Switch to call log. Click on the call just made and select "call" to make a call => no sound In step (14), I attempted to press a number instead of making a call, then I did (15), I could still hear sound. In other words, you have to dial out in (14) to make (15) soundless.
Unassigned myself after talked to Star, Hsinyi and aknow. They seem to already have a workaround or a temp solution for this bug. I'll let them explain more.
Assignee: echou → nobody
(In reply to Eric Chou [:ericchou] [:echou] from comment #21) > Update: > > I just flashed today's build on my Flame and had a more detailed test. > Please see test results below: > > = Step-by-step = > > ( 1) Full flash > ( 2) Launch keypad of Dialer app and make a call => sound can be heard In addition, if you turn off the keypad sound before step (2), there will be no sound in the call.
(In reply to Eric Chou [:ericchou] [:echou] from comment #21) > Update: > > I just flashed today's build on my Flame and had a more detailed test. > Please see test results below: > > = Step-by-step = > > ( 1) Full flash > ( 2) Launch keypad of Dialer app and make a call => sound can be heard > ( 3) Hangup > ( 4) Switch to call log. Click on the call just made and select "call" to > make a call => no sound > ( 5) Hangup > ( 6) Switch to call log. Click on the call just made and select "call" to > make a call => no sound > ( 7) Switch to keypad of Dialer app and press an "8" => A beep can be heard > ( 8) Switch to call log. Click on the call just made and select "call" to > make a call => no sound > (This is different from the previous test. See comment 12) > ( 9) Hangup > (10) Switch to call log. Click on the call just made and select "call" to > make a call => no sound > (11) During the call, click the keypad icon to open keypad, press an "8" => > A beep can be heard, and the sound is back. > (12) Hangup > > The following observation is really interesting: > > (13) Switch to call log. Make 3 consecutive calls (Call -> Hangup -> Call -> > Hangup -> Call -> Hangup) => Sound can be heard in all 3 calls. > (14) Launch keypad of Dialer app and make a call => sound can be heard > (15) Switch to call log. Click on the call just made and select "call" to > make a call => no sound > > In step (14), I attempted to press a number instead of making a call, then I > did (15), I could still hear sound. In other words, you have to dial out in > (14) to make (15) soundless. I can *not* duplicate in Nexus4 device. (Using the latest SW build)
The related bug here indicates that bug 999334 is actually the cause. I'm switching the qawanted request here to see if this reproduces on Tarako with the same SIM that reproduced the issue on Open C.
Issue is NOT reproducible using the same SIM that reproduced the issue on Open C with yesterday's Tarako build and today's master build. Sound can be heard if dialed from call log. Tested on: Device: Tarako 1.3T MOZ BuildID: 20140504014000 Gaia: 1177a857a3caeb8fd1feae94c83298a9144c2ff5 Gecko: d28bb1e73b91 Version: 28.1 Firmware Version: sp6821a_gonk4.0_user.pac Device: Buri MOZ BuildID: 20140505040201 Gaia: db338d3d4bc394bbddee1c35994d1b3dd4b1fac2 Gecko: 1204667a2935 Version: 32.0a1 Firmware Version: v1.2-device.cfg
Keywords: qawanted
To prove Star's patch of bug 984498 is not the cause of this issue, I checked out to Star's commit and gave another try. This is not reproducible and sound can be heard even I dialed from call log.
(In reply to Eric Chou [:ericchou] [:echou] from comment #27) > To prove Star's patch of bug 984498 is not the cause of this issue, I > checked out to Star's commit and gave another try. This is not reproducible > and sound can be heard even I dialed from call log. Then I cherry-picked aknow's patch for bug 999334. This issue can be reproduced.
Component: Gaia::Dialer → RIL
This should be fixed in the 5/8/2014 build. Can we confirm this?
Keywords: qawanted
Verified fixed on the Open C using: Gaia 1e0574b8f6b8a2a8d9d468878ce2b4c283fc9a84 SourceStamp 2a03b34c8953 BuildID 20140508040203 Version 32.0a1 Base Image: 4/29 I verified by testing from both the call log and contacts, and in both cases I am able to hear the call
Fixed by the dependency then per the above comment.
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: