vasanth Reporter
	Description • 10 years ago

[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?

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 1 • 10 years ago

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

	Hema Koka [:hema]
	Comment 2 • 10 years ago

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

	Hema Koka [:hema]
	Comment 3 • 10 years ago

Adding njpark to help with testing

	No-Jun Park [:njpark]
	Comment 4 • 10 years ago

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

	vasanth Reporter
	Comment 5 • 10 years ago

(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.

	Dominic Kuo [:dkuo] Assignee
	Comment 6 • 10 years ago

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

	No-Jun Park [:njpark]
	Comment 7 • 10 years ago

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

	Jenny Lee
	Comment 8 • 10 years ago

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

	No-Jun Park [:njpark]
	Comment 9 • 10 years ago

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

	David Flanagan [:djf]
	Comment 10 • 10 years ago

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?

	Dominic Kuo [:dkuo] Assignee
	Comment 11 • 10 years ago

(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!

	Dominic Kuo [:dkuo] Assignee
	Comment 12 • 10 years ago

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.

	Randy Lin [:rlin] - Be Mozillian on 2015/01/26
	Comment 13 • 10 years ago

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.

	bhavana bajaj [:bajaj]
	Comment 15 • 10 years ago

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

	Dominic Kuo [:dkuo] Assignee
	Comment 16 • 10 years ago

(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!

	Hema Koka [:hema]
	Comment 17 • 10 years ago

(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

	Dominic Kuo [:dkuo] Assignee
	Comment 19 • 10 years ago

Comment on attachment 8513582 [details]
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!

	Dominic Kuo [:dkuo] Assignee
	Comment 20 • 10 years ago

Comment on attachment 8513582 [details]
patch

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

	Jim Porter (:squib)
	Comment 21 • 10 years ago

Comment on attachment 8513582 [details]
patch

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

	Dominic Kuo [:dkuo] Assignee
	Comment 22 • 10 years ago

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

	Dominic Kuo [:dkuo] Assignee
	Comment 24 • 10 years ago

master: 64bb5641547df58180ed27e1b693c9b4158de737

	Dominic Kuo [:dkuo] Assignee
	Comment 25 • 10 years ago

Comment on attachment 8514762 [details]
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!

	Dominic Kuo [:dkuo] Assignee
	Comment 26 • 10 years ago

v2.1: e95ccb60589e98a576875879ad4105a53faeccba

	Yeojin Chung [:YeojinC]
	Comment 28 • 10 years ago

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