Closed Bug 1038165 Opened 10 years ago Closed 10 years ago

Music App paused/blocked when wired headset is inserted during audio playback through BT headset

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 verified, b2g-v2.1 verified)

RESOLVED FIXED
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: poojas, Assigned: dkuo)

References

Details

(Keywords: regression, Whiteboard: [caf priority: p2][CR 693960] [sprd332337])

Attachments

(3 files)

Steps to Reproduce: 1. Bootup the target 2. Pair and connect a Bluetooth headset 3. Start playing a music clip 4. Insert a wired headset Issue: A message "Music Paused during the call" pops up and Music app gets hanged. Even when there is no call on device
blocking-b2g: --- → 2.0?
Whiteboard: [CR 693960] → [caf priority: p1][CR 693960]
Adding qawanted to see if we can reproduce the issue and help find the cause here.
Keywords: qawanted
NI Alison to get urgent testing.
Flags: needinfo?(ashiue)
This bug does NOT repro on: Flame 2.1, Flame 2.0, Flame 1.4, Buri 2.1 Actual Result: Playing music over bluetooth attached to a Airband bluetooth headset then inserting a separate wired headset into the phone only produces a loudness warning message. Environmental Variables: Device: Flame Master Build ID: 20140714061512 Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847 Gecko: 340b19c14d3d Version: 33.0a1 (Master) Firmware Version: v122 ----------------------------------------------- Environmental Variables: Device: Flame 2.0 Build ID: 20140714071406 Gaia: 726ca25ef1dbb83d8ed8a902b46fb340a3f95927 Gecko: 002aee8237a3 Version: 32.0a2 (2.0) Firmware Version: v122 ----------------------------------------------- Environmental Variables: Device: Flame 1.4 Build ID: 20140711225112 Gaia: b7d36622c7df92c976c37520ccab25199c7ada91 Gecko: dbebcdab47aa Version: 30.0 (1.4) Firmware Version: v122 ----------------------------------------------- Environmental Variables: Device: Buri Master Build ID: 20140714061512 Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847 Gecko: 340b19c14d3d Version: 33.0a1 (Master) Firmware Version: v1.2device.cfg
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Pooja, Please provide more information on the DUT. Comment #3 says we cannot reproduce on Flame/Buri Thanks Hema
Flags: needinfo?(poojas)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Attached file music_issue.log
Test on Gaia 2c6c413ed729d465c52d6c2d5d458e2eee79e956 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965 BuildID 20140714160201 Version 32.0a2 Firmware Version: v122 This issue does not happen when I first tried this case, and the actual result just as what Cody mentioned; But after I reboot the device and tested again, this issue happened.
Flags: needinfo?(ashiue)
(In reply to ashiue from comment #5) > Created attachment 8455860 [details] > music_issue.log > > Test on > Gaia 2c6c413ed729d465c52d6c2d5d458e2eee79e956 > Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965 > BuildID 20140714160201 > Version 32.0a2 > Firmware Version: v122 > > This issue does not happen when I first tried this case, and the actual > result just as what Cody mentioned; But after I reboot the device and tested > again, this issue happened. Did you try this with 273MB mem config on Flame? Jim, can you help investigate this?
Flags: needinfo?(squibblyflabbetydoo)
Flags: needinfo?(ashiue)
(In reply to Hema Koka [:hema] from comment #6) > Jim, can you help investigate this? Not at the moment, no. My bluetooth headset is a couple of thousand miles away.
Flags: needinfo?(squibblyflabbetydoo)
(In reply to Hema Koka [:hema] from comment #6) > Did you try this with 273MB mem config on Flame? No, I did not try with 273MB. And this issue could not be reproduced when I tune memory to 273MB.
Flags: needinfo?(ashiue)
(In reply to Hema Koka [:hema] from comment #4) > Pooja, > > Please provide more information on the DUT. Comment #3 says we cannot > reproduce on Flame/Buri > Target: 8x10 QRD Gaia: "35a9b715e7348ec738ff6c8a59f50190390a06f2" Gecko "2fb60c777d3f82d580cba249e5e01a167a01de39" Version 32.0a2 Build ID 20140710185233 And as Ashiue mentioned this is not every time reproducible. reproducibility is 3/5.
Flags: needinfo?(poojas)
I'll set teh status falgs here, Given the reproducibility rate, this is worth investigating. Allision, can give this a couple of tries to see if this is reproducible in 1.4 or 2.1 as well ?
blocking-b2g: 2.0? → 2.0+
(In reply to bhavana bajaj [:bajaj] [NOT reading Bugmail, needInfo please] from comment #10) > I'll set teh status falgs here, Given the reproducibility rate, this is > worth investigating. > > Allision, can give this a couple of tries to see if this is reproducible in > 1.4 or 2.1 as well ? Yes, I can reproduce this issue on both 1.4 and 2.1 version. (default memory) [2.1] Gaia 0910be495385d90acdeaddbeaf1fba315aff57b0 Gecko https://hg.mozilla.org/mozilla-central/rev/7883d8e9f210 BuildID 20140715160202 Version 33.0a1 Firmware Version v122 [1.4] Gaia 393d72937727ad20e82b2ff7b13e3d7ff077a9f0 Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/932c37978d37 BuildID 20140715160201 Version 30.0 Firmware Version v122
Jim, Dominic has a bluetooth headset, please borrow it from him and investigate this out tomorrow. Thanks Hema
Assignee: nobody → squibblyflabbetydoo
(In reply to Cody Roesch [:croesch] from comment #3) > This bug does NOT repro on: Flame 2.1, Flame 2.0, Flame 1.4, Buri 2.1 > > Actual Result: Playing music over bluetooth attached to a Airband bluetooth > headset then inserting a separate wired headset into the phone only produces > a loudness warning message. > > Environmental Variables: > Device: Flame Master > Build ID: 20140714061512 > Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847 > Gecko: 340b19c14d3d > Version: 33.0a1 (Master) > Firmware Version: v122 > ----------------------------------------------- > Environmental Variables: > Device: Flame 2.0 > Build ID: 20140714071406 > Gaia: 726ca25ef1dbb83d8ed8a902b46fb340a3f95927 > Gecko: 002aee8237a3 > Version: 32.0a2 (2.0) > Firmware Version: v122 > ----------------------------------------------- > Environmental Variables: > Device: Flame 1.4 > Build ID: 20140711225112 > Gaia: b7d36622c7df92c976c37520ccab25199c7ada91 > Gecko: dbebcdab47aa > Version: 30.0 (1.4) > Firmware Version: v122 > ----------------------------------------------- > Environmental Variables: > Device: Buri Master > Build ID: 20140714061512 > Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847 > Gecko: 340b19c14d3d > Version: 33.0a1 (Master) > Firmware Version: v1.2device.cfg Cody, can you confirm you are trying the issue a couple of times here as I see allison be able to reproduce this. Wanted to identify that rate of reproducibility is the key issue here as I see some discrepancies.
Flags: needinfo?(croesch)
After testing this a little more, I'm able to get this issue across all devices. Not sure why i wasn't able to get this yesterday. This bug repro's on: Flame 2.1 Master, Flame 2.0, Flame 1.4 and Buri 2.1 Actual Results: When connected to a BT headset, and listening to music, if a wired headset is plugged into the DuT, the music will pause and a message "Music paused during the call" will appear. 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
Flags: needinfo?(croesch) → needinfo?(jmitchell)
3 of 4 builds tested today, the issue occurred on the first try. Yesterdays builds were not as generous for some reason.
I tested this with Flame using: Gaia 5f8b1b8a2da9e3b531eee817a669f57fa4d9b9c6 SourceStamp 913827496f65 BuildID 20140716000201 Version 32.0a2 Base: V122 + fonts 512 Memory Wired headphones were Bose Sony bluetooth headset was: Sony MDR 10RBT I also tried rebooting the device and wasn't able to reproduce it with this scenario. When I plugged in the wired headset while the BT was playing, all that happened was that the music player stopped, but the app did not hang. I then repeated the same STR with 273 and wasn't able to reproduce it either.
Flags: needinfo?(jmitchell)
So, we get an onscostatuschanged in shared/js/media/remote_controls.js, which fires self._commandHandler(AVRCP.PAUSE_PRESS); a bit later. From there, we wind up in apps/music/js/Player.js, and since we're 1) pausing, and 2) SCO is enabled, we show the little overlay. However, I have no idea why all this is happening. It would probably be best for someone familiar with Bluetooth to look into this (or at least point me at some documentation).
shuang/eric, can we get some help on the bluetooth side please.
Flags: needinfo?(shuang)
Flags: needinfo?(echou)
It looks like |connectSco| called via callscreen call_handler.js, this is why we can see SCO connection status changed event suddenly was been dispatched due to onheadphoneschange invoked. 7-18 11:25:41.419 292 292 I GeckoDump: !!!!!!!!!!!!!!!!switchToDefaultOut connectSco!!!!!!!!!!!!!!! 07-18 11:25:41.419 292 292 I GeckoDump: -----------connectSco------------- 07-18 11:25:41.419 292 292 I GeckoDump: connectSco dumpstack:BluetoothHelper/<.connectSco@app://callscreen.gaiamobile.org/shared/js/bluetooth_helper.js:98:15 07-18 11:25:41.419 292 292 I GeckoDump: switchToDefaultOut@app://callscreen.gaiamobile.org/js/calls_handler.js:664:7 07-18 11:25:41.419 292 292 I GeckoDump: cs_switchToDefaultOut@app://callscreen.gaiamobile.org/js/call_screen.js:408:5 07-18 11:25:41.419 292 292 I GeckoDump: onheadphoneschange@app://callscreen.gaiamobile.org/js/calls_handler.js:62:11 After that connectSco was been triggered again by callscreen while onscostatuschaged (because previously sco connected). 07-18 11:25:41.479 292 292 I GeckoDump: connectSco dumpstack:BluetoothHelper/<.connectSco@app://callscreen.gaiamobile.org/shared/js/bluetooth_helper.js:98:15 07-18 11:25:41.479 292 292 I GeckoDump: switchToDefaultOut@app://callscreen.gaiamobile.org/js/calls_handler.js:664:7 07-18 11:25:41.479 292 292 I GeckoDump: cs_switchToDefaultOut@app://callscreen.gaiamobile.org/js/call_screen.js:408:5 07-18 11:25:41.479 292 292 I GeckoDump: onscostatuschanged@app://callscreen.gaiamobile.org/js/calls_handler.js:69:9
Flags: needinfo?(shuang)
We are not in the middle of incoming/outgoing call session in this case, but callscreen still handle onheadphoneschange and trigger BT SCO connection during a2dp streaming, I think that doesn't make sense here. ni? Etienne.
Flags: needinfo?(echou) → needinfo?(etienne)
SCO/A2DP should be mutual exclusive, so I think this bug is not related to Music app but call screen.
Thanks Shawn, I think I got the issue and will take it over from Jim because the fix might need some knowledge of the bluetooth module in the system app, which I should be familiar with.
Assignee: squibblyflabbetydoo → dkuo
Dominic has identified the issue (not a music problem), but this probably won't make it by FC date. He will update with more information.
Whiteboard: [caf priority: p1][CR 693960] → [caf priority: p1][CR 693960]
Found bug 1026475 caused this regression. Ben, can you please describe why you made that change in bug 1026475? to connect the SCO when the telephony is not connected seems confused, and caused the other apps(like music) listen to SCO status behave wrong. I will probably fix this issue by checking the telephony status then decide to connect SCO or not, it should keep this original behavior and fix the issue in music.
Flags: needinfo?(btian)
Keywords: regression
Attached file patch
Etienne, would you please review this? thanks.
Attachment #8458853 - Flags: review?(etienne)
Changing the title to fit the reality.
Summary: Music App hangs when wired headset is inserted during audio playback through BT headset → Music App paused/blocked when wired headset is inserted during audio playback through BT headset
(In reply to Dominic Kuo [:dkuo] (Media Apps Work Week, July 14-18) from comment #24) > Found bug 1026475 caused this regression. > > Ben, can you please describe why you made that change in bug 1026475? to > connect the SCO when the telephony is not connected seems confused, and > caused the other apps(like music) listen to SCO status behave wrong. Bug 1026475 alters in-call audio path to match pre-2.0 UI. When both headphone and BT headset are connected, the callscreen audio path switch UI didn't show "headphone" but 3 options only: speaker, receiver, and BT headset. Therefore I made the behavior favor BT headset. The change intends to affect in-call audio path only. Also refer to bug 989233. Original behavior was to connect SCO when headphone is plugged in. In bug 989233 I thought headphone should be favored so removed it. And then in bug 1026475 I found the UI inconsistency so restored the original behavior. > I will probably fix this issue by checking the telephony status then decide > to connect SCO or not, it should keep this original behavior and fix the > issue in music. Agree. This is the correct fix to make other apps immune from callscreen audio path changes.
Flags: needinfo?(btian)
Thanks Ben, then I think my patch should be right to fix this issue since I didn't change the behaviour on selecting the destination which the audio will be routed. Let's wait for Etienne's review :)
Comment on attachment 8458853 [details] [review] patch Redirecting to Rik, but you're probably missing a new unit-test :)
Attachment #8458853 - Flags: review?(etienne) → review?(anthony)
Flags: needinfo?(etienne)
Comment on attachment 8458853 [details] [review] patch Instead of telephony.active, we should test 'displayed', a "global" to this module. This will make it more robust. telephony.active could be false if we only have one call and it is on hold. 'displayed' is true when the callscreen is open. And yup, we'll need one more test here. By using 'displayed', a test breaks so we need to update its title. And the new test should open the callscreen before trying to connect to SCO. Let me know if you want me to help with this test.
Attachment #8458853 - Flags: review?(anthony)
Thanks Dominic for addressing this issue. This should probably be in Bluetooth component
Component: Gaia::Music → Bluetooth
Thanks guys, I didn't aware I should add an unit test for this, I will address it then request review again. (In reply to Hema Koka [:hema] from comment #31) > Thanks Dominic for addressing this issue. This should probably be in > Bluetooth component Hema, this should be a callscreen issue because it connects SCO in a wrong timing then causes music to have wrong behaviour, I will change the component to dialer first since there is no callscreen component.
Component: Bluetooth → Gaia::Dialer
Comment on attachment 8458853 [details] [review] patch Rik, I have addressed the issue with the new tests, would you please review it again? thanks.
Attachment #8458853 - Flags: review?(anthony)
Comment on attachment 8458853 [details] [review] patch r+ with the tests modified for readability. Thanks!
Attachment #8458853 - Flags: review?(anthony) → review+
Whiteboard: [caf priority: p1][CR 693960] → [caf priority: p2][CR 693960]
Thanks Rik! master: cabe1a8891961e8654ef4a60491e9907c7217465
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
v2.0: 29266e18c35f4e72e35f1bba0e34f2fb6b995cc3
status-b2g-v1.4 already marked as affected. Please triage for v1.4.
Please land it to 1.4.
Flags: needinfo?(ryang)
Whiteboard: [caf priority: p2][CR 693960] → [caf priority: p2][CR 693960] [sprd332337]
Hi Dominic,could you please kindly help us to rebase 1.4 patch? Thank you so much.
Flags: needinfo?(ryang) → needinfo?(dkuo)
blocking-b2g: 2.0+ → 1.4+
I think we should mark approval‑gaia‑v1.4, right?
v1.4: eb3b185325901d4c04e2d43eb58d90835213bea9 I already uplifted to v1.4...please needinfo me again if we don't want this on v1.4.
Flags: needinfo?(dkuo)
blocking-b2g: 1.4+ → ---
blocking-b2g: --- → 1.4+
Needs to be covered by new test case to be covered.
Flags: in-moztrap?(ychung)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(ychung)
Flags: in-moztrap+
Attached video Verify_video.3gp
This issue has been verified successfully on Flame 2.0,2.1 See attachment: Verify_video.3gp Reproducing rate: 0/5 Flame2.0 build: Gaia-Rev 8d1e868864c8a8f1e037685f0656d1da70d08c06 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3 Build-ID 20141127000203 Version 32.0 Flame2.1 build: Gaia-Rev 5372b675e018b6aac97d95ff5db8d4bd16addb9b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f34377ae402b Build-ID 20141127001201 Version 34.0
QA Contact: croesch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: