1038162 - Audio is paused when headset is removed, while playback is happening through BT.

Status: VERIFIED FIXED

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

Description

[Pooja]

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.

Comment 1

[Hema Koka [:hema]]

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

Comment 2

[Dominic Kuo [:dkuo]]

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

Comment 3

[Dominic Kuo [:dkuo]]

Attachment: wip

Comment 4

[Dominic Kuo [:dkuo]]

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!

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 6

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 7

[Kai-Chih Hu [:khu]]

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.

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 9

[Kai-Chih Hu [:khu]]

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

Comment 10

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 11

[Dominic Kuo [:dkuo]]

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!

Comment 12

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 13

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: Bug 1038162 - Part 1: Add isA2dpConnected function to check A2dp connection status

Comment 14

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 15

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 16

[bhavana bajaj [:bajaj]]

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

Comment 17

[Cody Roesch [:croesch]]

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

Comment 18

[Dominic Kuo [:dkuo]]

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

Comment 19

[Kai-Chih Hu [:khu]]

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

Comment 20

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 21

[Hema Koka [:hema]]

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

Comment 22

[Dominic Kuo [:dkuo]]

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

Comment 23

[Pooja]

(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

Comment 24

[Dominic Kuo [:dkuo]]

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

Comment 25

[bhavana bajaj [:bajaj]]

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 ?

Comment 26

[Inder]

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.

Comment 27

[Dominic Kuo [:dkuo]]

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!

Comment 28

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 29

[Hema Koka [:hema]]

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

Comment 30

[Mike Habicher [:mikeh] (high bugzilla latency)]

Dominic, what is the ETA for landing this feature?

Comment 31

[Dominic Kuo [:dkuo]]

Attachment: new patch base on bug 929376

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!

Comment 32

[Dominic Kuo [:dkuo]]

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

Comment 33

[Jim Porter (:squib)]

Comment on attachment 8480504 [details] [review]
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. :)

Comment 34

[Dominic Kuo [:dkuo]]

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

Comment 35

[Dominic Kuo [:dkuo]]

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

Comment 36

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

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