1083129 - When BT & wired headsets are connected, behavior is not same while disconnecting one of them

Status: VERIFIED FIXED

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

Description

[vasanth]

[Blocking Requested - why for this release]:

Followup of bug 1073494
1. When both headsets are connected and if BT headset is removed, playback pauses.
2. When both headsets are connected and if wired headset is removed, playback continues.

Whether it pauses or not, I feel behavior has to be consistent in both cases.

Dominic,
Could you please look into this?

Comment 1

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

Please also see this issue bug 1082938 The user cannot pause the song after unpairing the BT headset.

Comment 2

[Hema Koka [:hema]]

Dominic, assigning this to you as well for investigation. Made this related bug: 1082938 a blocker because of broken function

Comment 3

[Hema Koka [:hema]]

Adding njpark to help with testing

Comment 4

[No-Jun Park [:njpark]]

This is reproducible in 2.1, but there is one detail that's worth mentioning:
when *both* headsets are connected, the music is heard through the BT headset, not wired headset.  So when the user hears the music via BT headset, disconnecting the wired headset won't affect the user, because it is not being used.

Once the wired headset is reconnected, then the phone recognizes the wired headset, and redirects the music to the wired headset from BT headset.  If BT headset is disconnected, then the music is paused even though the sound is coming out of the wired headset.  This should be fixed, but since there is a easy workaround (i.e. resume playing the music) not sure whether this qualifies as a blocker at this stage.

Version info:
Gaia-Rev        379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4853208cb48a
Build-ID        20141015001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141015.035504
FW-Date         Wed Oct 15 03:55:18 EDT 2014
Bootloader      L1TC00011840

Comment 5

[vasanth]

(In reply to No-Jun Park [:njpark] from comment #4)
> when *both* headsets are connected, the music is heard through the BT
> headset, not wired headset.

Just to clarify, When both headsets are connected, music is heard through last inserted headset.
Other than that I agree with your comment.

Comment 6

[Dominic Kuo [:dkuo]]

I will go to Jenny and discuss about this, let's have ux people to make the decisions, thanks.

Comment 7

[No-Jun Park [:njpark]]

need to check on 2.0 to see whether it's a regression

Comment 8

[Jenny Lee]

Hi Dominic,
Per discussion, playback should always pause whenever audio routing is changed. Thanks!

Comment 9

[No-Jun Park [:njpark]]

In 2.0, the behavior is a little different.
When wired headset and BT headset are both connected, the music always plays through the BT headset, even when wired headset is connected last.  I couldn't make the music to play on the wired headset while BT headset was connected.

But, when wired headset was disconnected, the music paused on BT headset.
When BT headset was disconnected, the music was paused as well, and I had to press play to make it play on the wired headset.

Since the music pauses when either headset is disconnected, I'll mark it as a regression.
Gaia-Rev        c6c6116ca225c2c934220ae6867e5a3256d65e00
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/24a2aa6bf1c4
Build-ID        20141016000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141016.031832
FW-Date         Thu Oct 16 03:18:42 EDT 2014
Bootloader      L1TC00011840

Comment 10

[David Flanagan [:djf]]

Dominic: this is a priority bug for CAF. Please let us know if you are able to make progress on it. If gecko work is needed, do you know who will be able to do that work?

Comment 11

[Dominic Kuo [:dkuo]]

(In reply to David Flanagan [:djf] from comment #10)
> Dominic: this is a priority bug for CAF. Please let us know if you are able
> to make progress on it. If gecko work is needed, do you know who will be
> able to do that work?

David, I am able to fix this bug and it has became a 2.1 blocker as well so gets higher priority. The current mozAudioChannelManager api should be able to handle this bug, and if not, I will let the gecko devs know, thanks!

Comment 12

[Dominic Kuo [:dkuo]]

I think my assumption(comment 11) may not apply to all the cases, especially when a bluetooth headset and a wired headphones are both connected to the phone before the music app is launched, because what music app is able to know is, which headset/headphones is connected(with |BluetoothAdapter.isConnected(A2DP_UUID)| and |mozAudioChannelManager.headphones|), but it does not equal to the audio is routing to one of the headset/headphones, we will misjudge the audio routing if the music app is launched after the headset/headphones are connected.

So, to fix this issue, it's better and a right direction to add gecko api to expose the audio routing information for gaia, but I guess it's too risky for 2.1 and it might take a while to discuss the new api, I will leave it to the gecko devs(Randy) and they should have some ideas.

Alternatively, since this is a 2.1 blocker, I will try to keep the audio routing information in system app(because system app will be launched before the bluetooth headset is connected), then pass it or use it then send the remote commands to music app, so that music app is able to know/decide when should it pause the player to response the audio routing changes.

Comment 13

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

On 2.2, I think we could add an read only attribute:AudioChannelManager.active to indicate this headset is active or not.
The behavior would be:
1. If headset was the last or only one plug-in device, this value would be true.
2. If user pair BT && headset is plugged, this value would be false because BT would be the last connect device.

Comment 15

[bhavana bajaj [:bajaj]]

NI :dkuo to confirm this is WIP and help with an eta here given we need CAF fixes in by 10/30.

Comment 16

[Dominic Kuo [:dkuo]]

(In reply to bhavana bajaj [:bajaj] from comment #15)
> NI :dkuo to confirm this is WIP and help with an eta here given we need CAF
> fixes in by 10/30.

For 2.1 the patch will be a workaround without gecko changes, so it will take while for me to implement it, hope I can have the first patch before tomorrow(10/29) and left a day for the peer(should be Jim) to review, thanks!

Comment 17

[Hema Koka [:hema]]

(In reply to Dominic Kuo [:dkuo] from comment #16)
> (In reply to bhavana bajaj [:bajaj] from comment #15)
> > NI :dkuo to confirm this is WIP and help with an eta here given we need CAF
> > fixes in by 10/30.
> 
> For 2.1 the patch will be a workaround without gecko changes, so it will
> take while for me to implement it, hope I can have the first patch before
> tomorrow(10/29) and left a day for the peer(should be Jim) to review, thanks!

Dominic, could you please put in a realistic ETA on marking this bug fixed with a workaround considering time to test and review. 

Thanks!
Hema

Comment 18

[Dominic Kuo [:dkuo]]

Attachment: patch

Comment 19

[Dominic Kuo [:dkuo]]

Comment on attachment 8513582 [details] [review]
patch

Jim, would you please take a look on this wip first? since this wip will be a workaround for 2.1, it's better to let you know that we need to make some changes in system and music(the remote controls module) or we won't be able to fix this bug to satisfy the ux needs.

I have tested it roughly and the wip works fine for me, what Jenny and me have decided the ux is: pause the music player when the active headphones/headset is unplugged/disconnected because, it implies the user probably wants to stop listening with the current setup, also we decided not to pause when plugging/connecting the headphones/headset because, the user should be expecting to continue to listen to the music, though it also changes the audio routing.

I should add some tests for the patch while you are checking it, thanks!

Comment 20

[Dominic Kuo [:dkuo]]

Comment on attachment 8513582 [details] [review]
patch

Jim, I have addressed those issues you mentioned on github and added unit tests for this patch, would you please review this? thanks!

Comment 21

[Jim Porter (:squib)]

Comment on attachment 8513582 [details] [review]
patch

I have a couple of small comments on GitHub, but assuming the tests are passing, this looks good to me!

Comment 22

[Dominic Kuo [:dkuo]]

The root cause of the issue(bug 1073494) is fixed on v2.1 and v2.2, changing the statuses.

Comment 23

[Dominic Kuo [:dkuo]]

Attachment: patch - v2.1

Comment 24

[Dominic Kuo [:dkuo]]

master: 64bb5641547df58180ed27e1b693c9b4158de737

Comment 25

[Dominic Kuo [:dkuo]]

Comment on attachment 8514762 [details] [review]
patch - v2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Bug 1073494.
[User impact] if declined: Bad ux if the user switches between the wired and bluetooth headphones/headset when listening to the music
[Testing completed]: Passed the gaia-try on master but v2.1 due to there is no test cases on v2.1 branch, but I have tested manually and works fine on real device.
[Risk to taking this patch] (and alternatives if risky): low.
[String changes made]: none.

Thanks!

Comment 26

[Dominic Kuo [:dkuo]]

v2.1: e95ccb60589e98a576875879ad4105a53faeccba

Comment 28

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.1 and 2.2.

Result: When the last connected headset is disconnected, the playback pauses. When the user resumes the playback, the audio is re-routed to the remaining headset.

1. First connected: BT / Last connected: wired ---> audio comes from wired.
Disconnect wired ---> playback pauses.

2. First connected: wired / Last connected: BT ---> audio comes from BT.
Disconnect BT ---> playback pauses.

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141105001204
Gaia: 154da5e17029a51002d5d9b7df39563d509edde6
Gecko: 3b0c3580a58d
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141105040206
Gaia: 7c9e7cabbde941b976e0e40a3a1d94e21aa9c5e9
Gecko: 62990ec7ad78
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0