[B2G][Helix][Audio][tianhuajian]The call mode can not be changed to Headset after insert the headset

RESOLVED FIXED

Status

Firefox OS
Gaia::Dialer
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: tianhuajian, Assigned: etienne)

Tracking

unspecified

Firefox Tracking Flags

(blocking-b2g:-, b2g-v1.2 fixed, b2g-v1.3 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; aff-kingsoft-ciba; .NET4.0C; .NET4.0E)

Steps to reproduce:

phone A is FFOS device , phone B is other phone
1. phone B call phone A
2. phone A connect the call
3. phone A chang the call mode to handfree 
4. insert the headset 


Actual results:

The phone A still in handfree mode


Expected results:

The phone A will changed to headset mode
(Reporter)

Updated

5 years ago
blocking-b2g: --- → hd?

Comment 1

4 years ago
(In reply to tianhuajian from comment #0)
> User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0;
> SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media
> Center PC 6.0; aff-kingsoft-ciba; .NET4.0C; .NET4.0E)
> 
> Steps to reproduce:
> 
> phone A is FFOS device , phone B is other phone
> 1. phone B call phone A
> 2. phone A connect the call
> 3. phone A chang the call mode to handfree 
> 4. insert the headset 
> 
> 
> Actual results:
> 
> The phone A still in handfree mode
> 
I heard the ring tone from both phone and headset if I insert my headset when the phone is ringing.
Marco, is it our design?

> 
> Expected results:
> 
> The phone A will changed to headset mode
Flags: needinfo?(mchen)

Comment 2

4 years ago
(In reply to Evelyn Hung [:evelyn] from comment #1)
> I heard the ring tone from both phone and headset if I insert my headset
> when the phone is ringing.
> Marco, is it our design?

Yes, this is under design.
This can avoid user ignore this call because he/her forget this phone on the table is plugged headset.
Flags: needinfo?(mchen)

Comment 3

4 years ago
(In reply to tianhuajian from comment #0)
Hi,

My first thought is that this is under design too.
When BT Handsfree profile is connected and it is on the phone call now, AudioManager will set ForceUse to BT_SCO in USE_COMMUNICATION.
https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/AudioManager.cpp#244

So during the phone call routing path will be SCO even headset is detected.

Comment 4

4 years ago
Hi UX team,

Could you give feedback about the behavior on bug description?
Thanks,
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 5

4 years ago
Flagging Francis to comment on the headset/speaker issue here as well.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
(In reply to Evelyn Hung [:evelyn] from comment #1)
> (In reply to tianhuajian from comment #0)
> > User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0;
> > SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media
> > Center PC 6.0; aff-kingsoft-ciba; .NET4.0C; .NET4.0E)
> > 
> > Steps to reproduce:
> > 
> > phone A is FFOS device , phone B is other phone
> > 1. phone B call phone A
> > 2. phone A connect the call
> > 3. phone A chang the call mode to handfree 
> > 4. insert the headset 
> > 
> > 
> > Actual results:
> > 
> > The phone A still in handfree mode
> > 
> I heard the ring tone from both phone and headset if I insert my headset
> when the phone is ringing.
> Marco, is it our design?
> 
> > 
> > Expected results:
> > 
> > The phone A will changed to headset mode

As mentioned in bug #910038, I would expect that connecting a headset should turn off the speaker mode. 

Having said that, while a headset is connected and speaker mode is off, I think it is good practice for an incoming call to route to both the headset and speaker to cover the situations that Marco described above in comment #2.
Flags: needinfo?(fdjabri)
> Having said that, while a headset is connected and speaker mode is off, I
> think it is good practice for an incoming call to route to both the headset
> and speaker to cover the situations that Marco described above in comment #2.

To be more specific here, an incoming call *ringtone* should route to both the speaker and a headset when a headset is connected.

Comment 8

4 years ago
Hi Macro,
-----My first thought is that this is under design too.
If it is a design , then how the voice route to the headset?
I think if the user insert the headset to the device , he wanted to hear the voice in headset.
Thanks

Comment 9

4 years ago
(In reply to lecky from comment #8)
> Hi Macro,
> -----My first thought is that this is under design too.
> If it is a design , then how the voice route to the headset?
> I think if the user insert the headset to the device , he wanted to hear the
> voice in headset.
> Thanks

Easy. there are two icons in the dialer app. One is for enabling speaker and the other for BT SCO.
When headset is coming and BT_SCO is enabled, user can press the BT_SCO icon to disable BT_SCO.
Finally user can hear the voice came from headset.

Comment 10

4 years ago
Since this behavior can be customized by each vendor and each UX export, I would suggest that it can be modified in dialer app.

Ex: dialer app can listen the headset in by AudioChannelManager then decide whether it want to disable BT_SCO or not.

Comment 11

4 years ago
(In reply to Marco Chen [:mchen] from comment #10)
> Since this behavior can be customized by each vendor and each UX export, I
> would suggest that it can be modified in dialer app.

Ex: dialer app can
> listen the headset in by AudioChannelManager then decide whether it want to
> disable BT_SCO or not.
This issue mentioned is wired headset.
And my question is : The phone has connect the call and in speaker mode ,why I insert the wired headset, the audio output can not change to headset?
Ex: Do you mean we modify the dialer app by ourselves to solve this issue?

Comment 12

4 years ago
(In reply to lecky from comment #11)
> (In reply to Marco Chen [:mchen] from comment #10)
> This issue mentioned is wired headset.
> And my question is : The phone has connect the call and in speaker mode ,why
> I insert the wired headset, the audio output can not change to headset?
> Ex: Do you mean we modify the dialer app by ourselves to solve this issue?

Yes. I suggest to modify dialer app for solving this issue.

Comment 13

4 years ago
(In reply to Marco Chen [:mchen] from comment #12)
> (In reply to lecky from comment #11)
> (In reply to Marco Chen [:mchen] from
> comment #10)
> This issue mentioned is wired headset.
> And my question is :
> The phone has connect the call and in speaker mode ,why
> I insert the wired
> headset, the audio output can not change to headset?
> Ex: Do you mean we
> modify the dialer app by ourselves to solve this issue?

Yes. I suggest to
> modify dialer app for solving this issue.
Hi Macro,
I reclear my request, my request is in step4 the speaker icon should be dark and the audio output should change to headset.
Do you mean this change should we modify the dialer app?
1. phone B call phone A
2. phone A connect the call
3. phone A chang the call mode to handfree 
4. insert the headset 



But I think this issue is audio channel bug.
Our request is the phone is in speaking ,when I insert the wired headset , the audio output should be wired headset, it

Comment 14

4 years ago
Hi Macro,
Since this behavior can be reproduced by each vendor and each UX export, I want to know whether you have any fix plan of this issue?
Thanks.

(In reply to Marco Chen [:mchen] (Summit 10/03 ~10/08) from comment #10)
> Since this behavior can be customized by each vendor and each UX export, I
> would suggest that it can be modified in dialer app.

Updated

4 years ago
Flags: needinfo?(mchen)

Comment 15

4 years ago
(In reply to lecky from comment #14)
> Hi Macro,
> Since this behavior can be reproduced by each vendor and each UX export, I
> want to know whether you have any fix plan of this issue?
> Thanks.
> 

Yes, I still recommend to fix it on dialer app.

The dialer app can use the Web API called MozAudioChannelManager to monitor the headset state.
If it find headset is plugged in and speaker is forced to enabled then try to disable the speakerForce from telephony Web API can achieve what you want.

Hi Etienne,

Based on comment 6 from Francis, it recommend that
  1. in voic_call state.
  2. User toggle the speaker icon (gaia called telephony web api to enable speakerForce)
  3. user insert the headset.
  4. The voice call should be routed to headset.

The problem we need gaia help is that
  1. from step 2, the web api there force the audio routing to speaker no matter any other audio output device is exist or not.
  2. So we need Gaia's help to monitor the headset state by MozAudioChannelManager web api then decide to disable speakerForce from telephony web api.

Thanks.
Flags: needinfo?(mchen) → needinfo?(etienne)
(Assignee)

Updated

4 years ago
Assignee: nobody → etienne
Flags: needinfo?(etienne)
(Assignee)

Comment 16

4 years ago
Created attachment 814864 [details]
Pointer to gaia PR

Here's a patch, works well for me!
Attachment #814864 - Flags: review?(anthony)
Comment on attachment 814864 [details]
Pointer to gaia PR

Yup, this does the work.

I'm a bit sad that we call CallScreen.turnSpeakerOff() rather than CallsHandler.turnSpeakerOff() (which would update the CallScreen) but that's not something to fix in this bug.
Attachment #814864 - Flags: review?(anthony) → review+

Comment 18

4 years ago
Hi Etienne,
I can not find the  calls_handler.js and calls_handler_test.js in our build.
Can you help me check it?
Our build version is as following:
【Gaia commit ID*】: V1.1HD
【Gecko commit ID*】:  1.1.0 HD

(In reply to Etienne Segonzac (:etienne) from comment #16)
> Created attachment 814864 [details]
Pointer to gaia PR

Here's a patch,
> works well for me!
Flags: needinfo?(etienne)
(Assignee)

Comment 19

4 years ago
(In reply to lecky from comment #18)
> Hi Etienne,
> I can not find the  calls_handler.js and calls_handler_test.js in our build.
> Can you help me check it?

It didn't land on master yet (waiting for a green travis build).
But if it becomes a 1.1 blocker we will probably need a specific patch for 1.1, it won't uplift easily.
Flags: needinfo?(etienne)
Thanks Etienne.

As this behaviour is consistent across v1.1 devices/releases, i'd recommend this change to be introduced on v1.2 onwards. Bumping to Koi?

(also noted comment 19 on possible large amount of work to land this on v1.1)
blocking-b2g: hd? → koi?
(Assignee)

Comment 21

4 years ago
(In reply to Wayne Chang [:wchang] from comment #20)
> Thanks Etienne.
> 
> As this behaviour is consistent across v1.1 devices/releases, i'd recommend
> this change to be introduced on v1.2 onwards. Bumping to Koi?
> 
> (also noted comment 19 on possible large amount of work to land this on v1.1)

Cool, uplifting this patch to 1.2 should not be an issue.
(Assignee)

Comment 22

4 years ago
https://github.com/mozilla-b2g/gaia/commit/1deb60f128b819212161de90205a6b5e1e97935d
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 23

4 years ago
hi Beatriz,
For this issue, Wayne Chang had said will be resolved in V1.2.
So please check whether you accept this result?
Thanks
Flags: needinfo?(wchang)
Flags: needinfo?(brg)

Updated

4 years ago
Flags: needinfo?(wchang)
(In reply to lecky from comment #23)
> hi Beatriz,
> For this issue, Wayne Chang had said will be resolved in V1.2.
> So please check whether you accept this result?
> Thanks
You can take v1.2. We do not land this functionality in v1.1. Agree with comment 20.
Flags: needinfo?(brg)

Updated

4 years ago
blocking-b2g: koi? → -
blocking-b2g: - → koi+
Whiteboard: checkin-needed
John, can you please assist with the uplift? :)
Flags: needinfo?(jhford)
Conflict here - triage originally decided this was a not a blocker for release, but was certainly something we should consider taking on an approval.
blocking-b2g: koi+ → -
Flags: needinfo?(jhford)
Whiteboard: checkin-needed
(In reply to Jason Smith [:jsmith] from comment #26)
> Conflict here - triage originally decided this was a not a blocker for
> release, but was certainly something we should consider taking on an
> approval.
I do not unerstand why koi+ was removed here. According to comment 21 the patch should fit in v1.2. Can we reset this to koi+?
Flags: needinfo?(jsmith)
(In reply to Beatriz Rodríguez [:brg] from comment #27)
> (In reply to Jason Smith [:jsmith] from comment #26)
> > Conflict here - triage originally decided this was a not a blocker for
> > release, but was certainly something we should consider taking on an
> > approval.
> I do not unerstand why koi+ was removed here. According to comment 21 the
> patch should fit in v1.2. Can we reset this to koi+?

Well, right. That means you should ask for approval to get this uplifted to 1.2. There was bug conflict that happened in triage with setting the blocking flag. It was intended as a not a blocker for release, but we could definitely ask for approval and take this onto 1.2.
Flags: needinfo?(jsmith)
We need this fix in v1.2. Nominating accordingly to koi+
blocking-b2g: - → koi?
(In reply to Beatriz Rodríguez [:brg] from comment #29)
> We need this fix in v1.2. Nominating accordingly to koi+

I think we made it very clear that this isn't a blocker for release. Please ask for approval.
blocking-b2g: koi? → -
Etienne - Can you nominate this for uplift?
Flags: needinfo?(etienne)
(Assignee)

Comment 32

4 years ago
(In reply to Jason Smith [:jsmith] from comment #31)
> Etienne - Can you nominate this for uplift?

Can I? :)
Not sure how to do this...

The patch is safe but I don't have a strong opinion (and I believe in the trains ;)).
Flags: needinfo?(etienne)

Updated

4 years ago
Component: General → Gaia::Dialer
(In reply to Etienne Segonzac (:etienne) from comment #32)
> (In reply to Jason Smith [:jsmith] from comment #31)
> > Etienne - Can you nominate this for uplift?
> 
> Can I? :)
> Not sure how to do this...
> 
> The patch is safe but I don't have a strong opinion (and I believe in the
> trains ;)).

You can do this by setting the flag "approval-gaia-v1.2" under details. Then, fill out the associated form.
(Assignee)

Comment 34

4 years ago
(In reply to Jason Smith [:jsmith] from comment #33)
> You can do this by setting the flag "approval-gaia-v1.2" under details.
> Then, fill out the associated form.

Thanks.
Like I said, don't have a strong opinion on this one, I'll let Beatriz ask for approval if needed.
Flags: needinfo?(brg)
Comment on attachment 814864 [details]
Pointer to gaia PR

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined: user cannot use the headset during a call
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky): read comment 32
[String changes made]:
Attachment #814864 - Flags: approval-gaia-v1.2?
One other note with the approval request - there's no string changes with this patch. The patch is simple with unit tests included. It looks safe to take into 1.2.
Flags: needinfo?(brg)

Updated

4 years ago
Duplicate of this bug: 910038
Comment on attachment 814864 [details]
Pointer to gaia PR

We've bee looking for this patch for a while now. I've approved it for 1.2
Attachment #814864 - Flags: approval-gaia-v1.2? → approval-gaia-v1.2+
Uplifted 1deb60f128b819212161de90205a6b5e1e97935d to:
v1.2: ff498298899bd60ecafc286f0dd780aa3331399d
status-b2g-v1.2: --- → fixed
Uplifted 1deb60f128b819212161de90205a6b5e1e97935d to:
v1.3 already had this commit
status-b2g-v1.3: --- → fixed
You need to log in before you can comment on or make changes to this bug.