1057490 - [FMRadio] The FM radio does not resume when denying an incoming call

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::FMRadio, defect)

Description

[pete siphantong [:Petes]]

Attachment: rr.txt

Description:
When the user is playing FM radio on speaker mode and denies an incoming call, the radio will not resume 

Repro Steps:
1) Update a Flame to 20140822040202
2) Insert headphones into your device
3) Open the FM Radio & start playing a station with sound & enable speaker mode
4) Call the phone with speaker mode active
5) When the incoming call appears, remove headphones, wait a few seconds, reattach the headphones
6) Deny call 

Actual:
radio does not resume

Expected:
radio resume 

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency: 3/3 - 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/11243/
See attached: video, logcat, https://www.youtube.com/watch?v=jxDRZu0PGxY

Comment 1

[pete siphantong [:Petes]]

This issue also reproduces on the Flame 2.1 (512mb), Open C 2.1, Flame 2.0 (319mb), Open C 2.0, Flame 1.4 (319mb), and the Open_C 1.4. The radio does not resume

Flame 2.1

Environmental Variables:
Device: Flame Master (512mb)
Build ID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Flame 2.0

Environmental Variables:
Device: Flame 2.0 (319mb)
Build ID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4

Environmental Variables:
Device: Flame 1.4 (319mb)
BuildID: 20140822063011
Gaia: f63cdae1a06c808443ed14de3cd13b61311426e0
Gecko: 7a467e895de5
Version: 30.0 (1.4) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 1.4

Environmental Variables:
Device: Open_C 1.4
BuildID: 20140822063011
Gaia: f63cdae1a06c808443ed14de3cd13b61311426e0
Gecko: 7a467e895de5
Version: 30.0 (1.4)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 2

[pete siphantong [:Petes]]

Updated video, https://www.youtube.com/watch?v=Lst3LlwXsYM

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

Seems minor since the user can tap play again and FM Radio works fine. Not nominating to block.

Comment 5

[Mike Lien[:mlien]]

nom 2.2? to see if this should be fixed or not

Comment 6

[Hema Koka [:hema]]

I think this is how it was since the original implementation. Adding Pin Zhang to confirm. 

Not blocking 2.2 since user has a way to resume FMRadio

Comment 7

[Pin Zhang [:pzhang] (inactive)]

Aha, this case is what we missed in bug 1037880 which introduced a work around to stop and resume the FM radio when the attention screen is shown and hidden. We also have almost the same logic, i.e. use some temporary variables to remember FM radio states, to stop and resume the FM radio when the headphone is unplugged and plugged, there are some logic conflicts.

As Randy mentioned in bug 1069887 comment 64, we are working on new audio channel strategy, and i think this case will be fixed after that (and probably need to revert bug 1037880). So I prefer just leave this bug open and wait instead of adding more workaround codes.

ni? Randy here, make sure this case is also be considered in bug 1113086.

Comment 8

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

So the story would be

1) Update a Flame to 20140822040202
2) Insert headphones into your device
3) Open the FM Radio & start playing a station with sound & enable speaker mode
4) Call the phone with speaker mode active
5) When the incoming call appears, remove headphones, wait a few seconds, reattach the headphones
^^^^^^^on this step, does fm radio has been resumed? After deny call, the fmradio app's status is stop.
6) Deny call 
I think bug 1113086 could handle this if on step 5, fmradio can be resumed and system app isn't allow it to play out audio through headset/speaker, the behavior would be the same as we expect.

Comment 9

[Pin Zhang [:pzhang] (inactive)]

(In reply to Randy Lin [:rlin] from comment #8)
> So the story would be
> 
> 1) Update a Flame to 20140822040202
> 2) Insert headphones into your device
> 3) Open the FM Radio & start playing a station with sound & enable speaker
> mode
> 4) Call the phone with speaker mode active
> 5) When the incoming call appears, remove headphones, wait a few seconds,
> reattach the headphones
> ^^^^^^^on this step, does fm radio has been resumed? After deny call, the
> fmradio app's status is stop.

When headphone is plugged in again, the FM radio will resume to play only if the FM radio is playing before the headphone is unplugged. But in this case, the FM radio has been disabled when the headphone is unplugged, because we stopped it when the attention screen is shown (bug bug 1037880). So i think we need to both fix bug 1113086 fix and revert bug 1037880 to make things right.

> 6) Deny call 
> I think bug 1113086 could handle this if on step 5, fmradio can be resumed
> and system app isn't allow it to play out audio through headset/speaker, the
> behavior would be the same as we expect.

Comment 10

[No-Jun Park [:njpark]]

qawanted to check whether this bug still reproduces on flame in 2.2 and master.

ni?ing dominic per hema's request.  When FM radio is stopped by pulling the headset, plugging it back in resumes the FM radio, but under this scenario FM radio does not resume, wondering whether the bug is about managing priority.

Comment 11

[Shally Li（leave from Mozilla）]

Hi No-Jun,

    I am able to repro this bug on latest Nightly Flame v2.2&3.0. Thanks.

See attachments: verify_v2.2.MP4 and logcat_1604.txt
Reproduce rate: 5/5

Repro STR:
1) Flash build.
2) Insert headphones.
3) Open the FM Radio & start playing a station with sound & enable speaker mode.
4) Call the phone with speaker mode active
5) When the incoming call appears, remove headphones, wait a few seconds, re-insert the headphones
**When removing and then re-inserting headphones,you can hear the sound of call ringtone from headphones and speaker.
6) Deny call.
**The FM radio is paused,user can tap "Play" button to play.

-------------------------------------------------------------------------------
Device: Flame 2.2 build(Affected)
Build ID               20150429002501
Gaia Revision          1b7aa7e60788668ed09abf76022dfa231dbe88d4
Gaia Date              2015-04-28 19:36:06
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d38ff4717f39
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150429.035717
Firmware Date          Wed Apr 29 03:57:29 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 3.0 build(Affected)
Build ID               20150429010205
Gaia Revision          6e35b0948c42a4398b8a5916015de167121683a1
Gaia Date              2015-04-28 16:06:07
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150429.043837
Firmware Date          Wed Apr 29 04:38:48 EDT 2015
Bootloader             L1TC000118D0

Comment 12

[Shally Li（leave from Mozilla）]

Attachment: logcat_1604.txt

Comment 13

[Shally Li（leave from Mozilla）]

Attachment: verify_v2.2.mp4

Comment 14

[Dominic Kuo [:dkuo]]

Pin has explained the root cause in comment 9, bug 1037880 used a workaround to disable the fm radio, so before answering the incoming call, the fm radio is already disabled by that workaround, and it messed up the antenna state then result in fm radio disabled.

This issue is not caused by the current audio channel management, but because bug 1037880 is a workaround of the audio channel competing, I would suggest we fix it after the new audio channel service(bug 1089539) landed, or we will just add another workaround above an existing workaround.

Comment 15

[No-Jun Park [:njpark]]

[Tracking Requested - why for this release]:
putting it to backlog until bug 1089539 lands.

Comment 16

[BMO Automation]

Firefox OS is not being worked on