Pooja Reporter
	Description • 10 years ago

Steps to Reproduce:
    1. Bootup the Target.   
    2. Connect the wired headset.
    3. Pair and connect to a BT headset.
    4. Music routes to BT when playback is started.
    5. Remove the wired headset.

Actual behavior:
 Audio playback pauses.
Expected behavior:
 Music should continue seamlessly on BT.

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

Dominic, can you try this out and see if you are able to reproduce this issue?

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

Yes, and I just reproduced it on my flame, this is an confirmed issue.

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

The straightforward fix for this issue is to get the a2dp connection status when the headphoneschange event from mozAudioChannelManager fires, but currently it seems we can only wait for the a2dp status when the connection changes(BluetoothAdapter.ona2dpstatuschanged).

Shawn, do you know any better way to actively get the a2dp connection status instead of waiting the status changes passively?(something like BluetoothAdapter.isScoConnected) or any alternative way to know the correct a2dp status? thanks!

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 5 • 10 years ago

Ah, we don't have API to get a2dp status now unless you listen ona2dpstatuschanged.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 6 • 10 years ago

(In reply to Dominic Kuo [:dkuo] (Media Apps Work Week, July 14-18) from comment #4)
> The straightforward fix for this issue is to get the a2dp connection status
> when the headphoneschange event from mozAudioChannelManager fires, but
> currently it seems we can only wait for the a2dp status when the connection
> changes(BluetoothAdapter.ona2dpstatuschanged).
> 
> Shawn, do you know any better way to actively get the a2dp connection status
> instead of waiting the status changes passively?(something like
> BluetoothAdapter.isScoConnected) or any alternative way to know the correct
> a2dp status? thanks!

Not quite sure the requirement you mentioned, is |BluetoothAdapter.ona2dpstatuschanged| not enough? If not, we can think about adding API. Can you elaborate the requirement?

	Kai-Chih Hu [:khu]
	Comment 7 • 10 years ago

Dominic and Shawn, can you two have discussions face to face and provide some suggestion here? Since you two are in the same office, to discuss f2f could be the best way, and we can speed up the process. What do you think? Thanks.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 8 • 10 years ago

(In reply to Kevin Hu [:khu] from comment #7)
> Dominic and Shawn, can you two have discussions face to face and provide
> some suggestion here? Since you two are in the same office, to discuss f2f
> could be the best way, and we can speed up the process. What do you think?
> Thanks.
He is in Media apps work week, so we're not in the same office now! I will catch him when is online.

	Kai-Chih Hu [:khu]
	Comment 9 • 10 years ago

Oh! Sorry, I wasn't aware of it. Thanks, Shawn!

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 10 • 10 years ago

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #6)
> (In reply to Dominic Kuo [:dkuo] (Media Apps Work Week, July 14-18) from
> comment #4)
> > The straightforward fix for this issue is to get the a2dp connection status
> > when the headphoneschange event from mozAudioChannelManager fires, but
> > currently it seems we can only wait for the a2dp status when the connection
> > changes(BluetoothAdapter.ona2dpstatuschanged).
> > 
> > Shawn, do you know any better way to actively get the a2dp connection status
> > instead of waiting the status changes passively?(something like
> > BluetoothAdapter.isScoConnected) or any alternative way to know the correct
> > a2dp status? thanks!
> 
> Not quite sure the requirement you mentioned, is
> |BluetoothAdapter.ona2dpstatuschanged| not enough? If not, we can think
> about adding API. Can you elaborate the requirement?

I guess I know the problem is and why we need this API. I will prepare a patch for a2dp status query.

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

Shawn,

Sorry about the unclear description, let me re-describe it again:
The use case here is, Music app will try to pause the player when the wired headphones is unplugged, but this bug is the exception because the audio is still routing to the connected bluetooth headset, so Music shouldn't pause the player since the sounds won't come out from the phone speaker.

This means when the wired headphones is unplugged, Music should also check if a2dp is connected, which also means the user is using the bluetooth headset. And currently we can only use |BluetoothAdapter.ona2dpstatuschanged| to get the a2dp status, but Music cannot know the current status if the ona2dpstatuschanged does not fire yet(because a2dp is already connected). So what we want here is to actively get the a2dp status, just like the api |BluetoothAdapter.isScoConnected| which we can query the SCO status, does this make sense?

Or if not, is there any alternative way to know a2dp is connected or the bluetooth headset is connected? please advice, thanks!

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 12 • 10 years ago

(In reply to Dominic Kuo [:dkuo] (Media Apps Work Week, July 14-18) from comment #11)
> Shawn,
> 
> Sorry about the unclear description, let me re-describe it again:
> The use case here is, Music app will try to pause the player when the wired
> headphones is unplugged, but this bug is the exception because the audio is
> still routing to the connected bluetooth headset, so Music shouldn't pause
> the player since the sounds won't come out from the phone speaker.
> 
> This means when the wired headphones is unplugged, Music should also check
> if a2dp is connected, which also means the user is using the bluetooth
> headset. And currently we can only use
> |BluetoothAdapter.ona2dpstatuschanged| to get the a2dp status, but Music
> cannot know the current status if the ona2dpstatuschanged does not fire
> yet(because a2dp is already connected). So what we want here is to actively
> get the a2dp status, just like the api |BluetoothAdapter.isScoConnected|
> which we can query the SCO status, does this make sense?
> 
> Or if not, is there any alternative way to know a2dp is connected or the
> bluetooth headset is connected? please advice, thanks!

I think unless we send system message to notify connection status for Music app, we don't have other way to get a2dp connection status. But in general, it seems that system message is not our option (only via event handler). As the following reason: If we kill Music app and re-launch music app, Music app still cannot get a2dp status.

So we need to add API to query a2dp status anyway.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 14 • 10 years ago

See also https://bugzilla.mozilla.org/show_bug.cgi?id=929376

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 15 • 10 years ago

Oh. I was wrong. It looks like system app actually records a2dp connection status.
See
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth.js#L45
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth.js#L166

So, can you get status from system app? Sorry I'm not sure Music can directly system app anyway.

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

qawanted to confirm what branches are affected here? That may help bisect the issue.

	Cody Roesch [:croesch]
	Comment 17 • 10 years ago

This bug repro's on: Flame 2.1 Master, Flame 2.0 and Buri 2.1

Actual Results: When connected to a BT headset, and listening to music, if a wired headset that is connected is pulled out, the music through the wireless BT headset will pause.

Environmental Variables:
Device: Flame Master
BuildID: 20140716065602
Gaia: d29773d2a011825fd77d1c0915a96eb0911417b6
Gecko: f6e46d1fc903
Version: 33.0a1 (Master) 
Firmware Version: v122
-----------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140716084350
Gaia: 5fa5611fc747d397dbaa2c5ccdc776f1dfd2b6e8
Gecko: 3045ff641a0b
Version: 32.0a2 (2.0)
Firmware Version: v122
-----------------------------------------------
Environmental Variables:
Device: Flame 1.4
Build ID: 20140716073943
Gaia: edec55eb65b4b8be3e44bedab2949f295784dff1
Gecko: 90162ab32776
Version: 30.0 (1.4)
Firmware Version: v122
-----------------------------------------------
Environmental Variables:
Device: Buri Master
Build ID: 20140716065602
Gaia: d29773d2a011825fd77d1c0915a96eb0911417b6
Gecko: f6e46d1fc903
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg

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

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #15)
> Oh. I was wrong. It looks like system app actually records a2dp connection
> status.
> See
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth.
> js#L45
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth.
> js#L166
> 
> So, can you get status from system app? Sorry I'm not sure Music can
> directly system app anyway.

Thanks Shawn, but as we discussed on IRC, system app shouldn't directly expose any information to the other apps, though bluetooth information can be access if you have bluetooth permission so music should do this by its own.

I think I will first go this approach: since we already have a media playback widget under the system app, we could let that widget to send the a2dp status to the music app(via IAC), this should make sense because we already passing the metadata and play status between system and music, and the a2dp status could be one of them, so music should be able to get the latest a2dp by the status sent from the media playback widget.

	Kai-Chih Hu [:khu]
	Comment 19 • 10 years ago

Hema, can you share with us your thoughts about the reason to mark this with 2.0+ blocker? Thanks.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 20 • 10 years ago

(In reply to Dominic Kuo [:dkuo] (Media Apps Work Week, July 14-18) from comment #18)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #15)
> > Oh. I was wrong. It looks like system app actually records a2dp connection
> > status.
> > See
> > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth.
> > js#L45
> > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth.
> > js#L166
> > 
> > So, can you get status from system app? Sorry I'm not sure Music can
> > directly system app anyway.
> 
> Thanks Shawn, but as we discussed on IRC, system app shouldn't directly
> expose any information to the other apps, though bluetooth information can
> be access if you have bluetooth permission so music should do this by its
> own.
> 
> I think I will first go this approach: since we already have a media
> playback widget under the system app, we could let that widget to send the
> a2dp status to the music app(via IAC), this should make sense because we
> already passing the metadata and play status between system and music, and
> the a2dp status could be one of them, so music should be able to get the
> latest a2dp by the status sent from the media playback widget.
Hi dkuo,
Thanks a lot. Then I think I don't need to deal with API now, right?

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

This does not block 2.0 release (we were assuming that it is a regression). We can look into the fix for next release. Dominic is looking into a fix.

Thanks
Hema

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

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #20)
> Hi dkuo,
> Thanks a lot. Then I think I don't need to deal with API now, right?

Yes, for now I think, but it's still nice to have the api fixed if we have time to do it, I am currently not blocked by the api and thanks for helping this!

	Pooja Reporter
	Comment 23 • 10 years ago

(In reply to bhavana bajaj [:bajaj] [NOT reading Bugmail, needInfo please] from comment #16)
> qawanted to confirm what branches are affected here? That may help bisect
> the issue.

Its a regression. Was there in V1.3 and V1.4 too

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

(In reply to Pooja from comment #23)
> (In reply to bhavana bajaj [:bajaj] [NOT reading Bugmail, needInfo please]
> from comment #16)
> > qawanted to confirm what branches are affected here? That may help bisect
> > the issue.
> 
> Its a regression. Was there in V1.3 and V1.4 too

I think we never handle this case in Music app so probably not a regression.

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

Ni on inder here as this needs to removed from 2.0 FC CAF metabug as discussed offline that this is a long standing regression and something we could get a waiver on for 2.0 and get this fixed in 2.1 ?

	Inder
	Comment 26 • 10 years ago

Waiver for 2.0. Moving to 2.1 blocking, please change the project blocking flags to reflect 2.1 fix. We need it fixed in 2.1.

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

Since this does not block 2.0 now so I will hold my wip because it's kind of workaround to fix this issue.

Shawn, does bluetooth team has the plan to fix bug 929376 for 2.1? it would be nice to have it fixed and we don't have to use the trick I have in my wip to fix this issue, thanks!

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 28 • 10 years ago

(In reply to Dominic Kuo [:dkuo] from comment #27)
> Since this does not block 2.0 now so I will hold my wip because it's kind of
> workaround to fix this issue.
> 
> Shawn, does bluetooth team has the plan to fix bug 929376 for 2.1? it would
> be nice to have it fixed and we don't have to use the trick I have in my wip
> to fix this issue, thanks!

If we move this bug to 2.1, I think we can handle it to avoid a tricky workaround.

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

Moving this into 2.1 milestone (dependency bug https://bugzilla.mozilla.org/show_bug.cgi?id=929376 is also being fixed in 2.1)

	Mike Habicher [:mikeh] (high bugzilla latency)
	Comment 30 • 10 years ago

Dominic, what is the ETA for landing this feature?

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

Jim, would you please review this patch? I also did some tiny refactor on the part we moved from Player.js to remote_controls.js, which make more sense to the whole module, and should be easy to understand, thanks!

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

(In reply to Mike Habicher [:mikeh] from comment #30)
> Dominic, what is the ETA for landing this feature?

If the patch looks good to Jim and I think we should be able to land it before this weekend, thanks.

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

Comment on attachment 8480504 [details]
new patch base on bug 929376

I haven't had a chance to try the patch out, but this looks like it does the right thing, and I like that we have one less thing in Player.js. :)

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

The gaia-try seems closed for now and I am not sure if I can land this patch or not...

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

This patch has no new test cases and didn't break the existing tests, so I have landed it first since gaia-try is closed for now.

master: 56039937bbdfddbad794bded4298da5584b99397

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

This is verified fixed on the Flame 2.1 and Flame 2.2 

The music reroutes to the BT headset and does not pause when the wired headset is unplugged.

Flame 2.1 

Device: Flame 2.1 
BuildID: 20141012001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.2 

Device: Flame 2.2 Master  KK (319mb) (Full Flash)
BuildID: 20141012040203
Gaia: 717ad4e8b7fc10ab8248500d00ba5ba0977fa8ab
Gecko: 44168a7af20d
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0