1157824 - Firefox Hello call audio does not route to headphones

Status: RESOLVED WONTFIX

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

Description

[Diego Wilson [:diego]]

Tested on Flame with FxOS v2.2

STR:
1. Insert heaphones
2. Open Firefox Hello
3. Make a call

The audio is heard on the loud speaker. If I unplug/plug the headphones during the call then the audio routes to the headphones as expected.

Comment 1

[Keven Kuo [:kkuo]]

Hi! Steven,

Looks like audio channel related.
Need your help to take a look.

--
Keven

Comment 2

[StevenLee[:slee]]

Alastor,
 
Please check this bug.

Thanks

Comment 3

[Alastor Wu [:alwu]]

Ok, I will check it later.

Comment 4

[Alastor Wu [:alwu]]

Sorry, Diego,
I don't understand this issue. 
Could you describe more specific about it?
You mean that after replug the headphone, the audio didn't came out from the headphone?

I tested it on Flame v2.2. 
If I unplug the headphones, then replug it. The routing is still by the headphone.
Thanks!

Comment 5

[Diego Wilson [:diego]]

(In reply to Alastor Wu [:alwu] from comment #4)
> Sorry, Diego,
> I don't understand this issue. 
> Could you describe more specific about it?
> You mean that after replug the headphone, the audio didn't came out from the
> headphone?

If I plug in the headphones before making a call then the audio goes through the loud speaker, even though the headphones are plugged in.

Comment 6

[Keven Kuo [:kkuo]]

(In reply to Alastor Wu [:alwu] from comment #4)
Hi! Alastor,

Could you try it on Nexus 5 which is 5.1 based?
You can find the device from QA team. Thanks

--
Keven

Comment 7

[Alastor Wu [:alwu]]

Hi, Keven,
Now I can reproduce this issue on the Flame. Previous I can't reproduce the issue is due to that I used the audio mode to make a call. 
The issue only happened on the video mode.

Comment 8

[Alastor Wu [:alwu]]

As I observation, there are two reasons caused in this issue.

This issue only can be reproduce on specific condition.
Condition 1 : Receive a video call.
Condition 2 : After condition1, make any video call or receive any video call

---

Here is my root cause analysis.

(1) App forgot turn off the speaker
When user answered the call, the app would call the SetForcespeaker(true). After that, the audio routing would be changed to the speaker. The app should call SetForcespeaker(false) again.
I found that if users make a call instead of answer a call, the SetForcespeaker(false) would be triggered after the SetForcespeaker(true).

(2) The unreleased SpeakerManager
Because of condition1, after the call was ended, we still had a SpeakerManager which would set the output routing to the speaker. 

In our expectation, this SpeakerManager should not effect the next call, right? BUT! For some unknown reason, this SpeakerManager didn't be destroyed, and it was still alive.

Therefore, all other new calls sound would be out from the speaker. When the new call is coming, the SpeakerManagerService would check all SpeakerManagers, and then set the output routing by them. 

(3) The redundant SpeakerManager
As I mentioned in condition2, the app would create the new SpeakerManager when there has a new call. And this SpeakerManager doesn't be destroyed untill the app is shoutdown. 
I think the Gaia should only use one instance to avoid this case.

---

Hi, José,
Could you give me some suggestion about that?
Is my assumption reasonable?
Very appreciate :)

Comment 9

[Alastor Wu [:alwu]]

Hi, Adam,
Sorry to bother you,
Could you give me some suggestions?

About this issue, I made the analysis in the comment8, and I think this issue should be solved in Gaia. 

Here is my proposal, 
(1) To set the speaker status when we receive the call during using the headset/headphone.
    - I think the app forgets to check that
(2) Use the singleton SpeakerManager, instead of creating a new one
    - The SpeakerManagers didn't be destroyed because someone still reference them. 
      Therefore, we would have the wrong speaker status.

Very appreciate your help :)

Comment 10

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Alastor Wu [:alwu] from comment #8)

Sorry for the lag Alastor.

> Could you give me some suggestion about that?
> Is my assumption reasonable?

You are rigth. The app needs some refactor around the usage of the SpeakerManager API. So it's not a platform issue. The main issue here is that we are not turning off the speaker once the call ends and the SpeakerManager API has state. The API is used here and there (too many places) and a deep refactor should be needed on the app side (Gaia side as you mentioned).

> Very appreciate :)

Sorry for the lag again.

Comment 11

[Alastor Wu [:alwu]]

Thanks, José :)

According to the comment10, free it and transform to the app side.

Comment 12

[Maria Angeles Oteo (:oteo)]

I am also seeing the issue with Loop master version and 2.2 Release although it works correctly in 2.0 Release so setting the status tracking flags according to this.

Environment variables for 2.0 release:
flame KK v2.0 (18D base)
Gecko-8e1b864
Gaia-84898ca
Buid ID:20150503051145
Platform version: 32.0

Environment variables for 2.2 release:
flame KK v2.2 (18D base)
Gecko-b86bf7e
Gaia-8d14361
Buid ID:20150503062854
Platform version: 37.0

Just FYI testing this bug, I've detected an issue in both branches that it seems we didn't detect when releasing 1.1.1 Loop mobile version, I've just filed a bug for it. See Bug 1160949 for more info.

Comment 13

[Maria Angeles Oteo (:oteo)]

As Jose Antonio explains in comment 10, for fixing this issue in 2.2 Firefox OS release, we need to do some kind of in refactor Firefox Hello Mobile application.

Released Loop Mobile versions (1.1.1 and 1.1) were initially planned to be landed on 2.0 FxOS and I think there are no plans to maintain the application for FxOS future versions, at least for 2.2. 

Once it's been clarified there is not any issue to fix in 2.2 Firefox OS platform, in case Loop mobile wanted to be supported in 2.2 FxOS version, it was agreed that Mozilla team would tackle so setting ni to Product team (Romain as Product owner) to make the decision here.

Comment 14

[Dylan Oliver [:doliver]]

Based on conversations this week, we will no longer block the CAF 2.2 metabug on Hello app issues.

Comment 15

[Bobby Chien]

triage: as discussion with EPMs, remove from 2.2+ and add to tracking-b2g.

Comment 16

[Romain Testard [:RT]]

Clearing NI - Hello bugs on 2.2 won't be fixed since Hello won't be released with 2.2.

Comment 17

[Maria Angeles Oteo (:oteo)]

Updating the corresponding tracking flag according to Romain's answer

Comment 18

[Bobby Chien]

Hello app doesn't exist in 2.5.