[Call] Inserting headphones doesn't disable speakerphone

RESOLVED DUPLICATE of bug 910584

Status

P5
normal
RESOLVED DUPLICATE of bug 910584
5 years ago
5 years ago

People

(Reporter: leo.bugzilla.gecko, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
We found some issues about speaker mode. We need to prepare fixed issues for the next model.
-------------------------------
[Tester`s Action]
1. It is on the call state
2. Enable the speaker mode
3. Plug the headset
[Symptom]
I don`t hear calls from the headset. 
[Expected]
should route sound path from the speaker to the headset.
-------------------------------
[Tester`s Action]
1. It is on the call state
2. Enable the speaker mode
3. Connect BT SCO
[Symptom]
We can hear calls from BT headset, but it dosen`t toggle the button of speaker mode.
[Expected]
It should disable the button of speaker mode.

Updated

5 years ago
blocking-b2g: --- → leo?
Please split the BT issues into a separate bug.
Flags: needinfo?(leo.bugzilla.gecko)
Summary: [Call]It dosen`t disable speaker mode after plugging headset → [Call] Inserting headphones doesn't disable speakerphone
Marco, I think the first part about wired headphone volume + handset volume implies a regression, right?
Flags: needinfo?(mchen)
(In reply to leo.bugzilla.gecko from comment #0)
> -------------------------------
> [Tester`s Action]
> 1. It is on the call state
> 2. Enable the speaker mode
> 3. Plug the headset
> [Symptom]
> I don`t hear calls from the headset. 
> [Expected]
> should route sound path from the speaker to the headset.

From technical point of view the code as below forced to use Speaker path as output device. So even headset is detected by AudioManager, the AudioPolicyManager still use Speaker to output sound because it is explicitly forced by someone.
https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#2596

From user point of view, since user toggle the speaker mode on already, device should keep to output from speaker until user toggle speaker mode off. This would need our UX team to explain this.
Flags: needinfo?(mchen) → needinfo?(firefoxos-ux-bugzilla)
(Reporter)

Comment 4

5 years ago
I registered BT issue, Bug 911859
Flags: needinfo?(leo.bugzilla.gecko)

Comment 5

5 years ago
Flagging Francis, whom I think responded to a similar issue last week. The expectation is that headset "takes over" from speaker, but I'll let Francis speak to this further.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
(In reply to leo.bugzilla.gecko from comment #0)
> We found some issues about speaker mode. We need to prepare fixed issues for
> the next model.
> -------------------------------
> [Tester`s Action]
> 1. It is on the call state
> 2. Enable the speaker mode
> 3. Plug the headset
> [Symptom]
> I don`t hear calls from the headset. 
> [Expected]
> should route sound path from the speaker to the headset.
> -------------------------------
> [Tester`s Action]
> 1. It is on the call state
> 2. Enable the speaker mode
> 3. Connect BT SCO
> [Symptom]
> We can hear calls from BT headset, but it dosen`t toggle the button of
> speaker mode.
> [Expected]
> It should disable the button of speaker mode.

I agree with the expected behavior described in the bug. Although the user has explicitly turned speaker mode on, connecting a headset should be enough to turn the speaker mode off.
Flags: needinfo?(fdjabri)
Ok, If this is the decision then I suggest dialer app to handle this case.
Since speaker enabling is fired by dialer app it would be better that dialer app detects headset status then disable speaker enabling.
David,

This bug suggests that it is a dialer issue. Please reassign appropriately.
Flags: needinfo?(dscravaglieri)
Ivan

Please check if other partners need this bug fix.
Flags: needinfo?(itsay)
Hi Preeti,

Already checked with partner and this one is not the blocker.
Flags: needinfo?(itsay)
triage: blocking- based on comment #10
blocking-b2g: leo? → -
this bug has been minused so clear ni?
Flags: needinfo?(dscravaglieri)
Hi all,

If UX confirmed this behavior, does it belong to V1.2 or V1.3 scope?

Thanks.
blocking-b2g: - → koi?

Updated

5 years ago
See Also: → bug 912384
Moving it to 1.3.
blocking-b2g: koi? → 1.3?
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 910584
You need to log in before you can comment on or make changes to this bug.