Closed Bug 1083129 Opened 5 years ago Closed 5 years ago
When BT & wired headsets are connected, behavior is not same while disconnecting one of them
[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?
Please also see this issue bug 1082938 The user cannot pause the song after unpairing the BT headset.
Dominic, assigning this to you as well for investigation. Made this related bug: 1082938 a blocker because of broken function
Assignee: nobody → dkuo
Adding njpark to help with testing
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
(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.
I will go to Jenny and discuss about this, let's have ux people to make the decisions, thanks.
Flags: needinfo?(dkuo) → needinfo?(jelee)
need to check on 2.0 to see whether it's a regression
Hi Dominic, Per discussion, playback should always pause whenever audio routing is changed. Thanks!
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
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?
(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!
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.
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.
NI :dkuo to confirm this is WIP and help with an eta here given we need CAF fixes in by 10/30.
(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!
(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
Whiteboard: [caf priority: p2][CR 739419] → [caf priority: p2][CR 739419][eta: 10/31]
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!
Attachment #8513582 - Flags: feedback?(squibblyflabbetydoo)
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 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!
Attachment #8513582 - Flags: review?(squibblyflabbetydoo) → review+
The root cause of the issue(bug 1073494) is fixed on v2.1 and v2.2, changing the statuses.
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!
Attachment #8514762 - Flags: approval-gaia-v2.1?(bbajaj)
Attachment #8514762 - Flags: approval-gaia-v2.1?(bbajaj) → approval-gaia-v2.1+
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.