User-Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 FTR- 1. Open Music app and play a song 2. Open Telegram or any other app where you can expect any notification soon 3. Lock the phone. 4. As soon as notification comes (and notification sound plays) music stops. 5. As I open/swipe to music app, it automatically start playing music again. Device logs same as bug#1214898

Hema, Can you confirm if this is the expected behavior or if its a bug? THanks

This doesn't sound right, but it's probably an audio channel issue. The music app doesn't have any direct control over this.

I can't reproduce this issue on following buildID - 20151023160551. My reproduce steps is like that, 1. Playing Music (content type) 2. Receive the SMS message (notification type) or Play the notification sound from Settings app 3. Hear the notification sound, and the music is still playing but fading its volume Therefore, I think the audio competing policy (notification v.s. content) is no problem. If the music is paused by other sound, that means other apps use the wrong audio channel type. (ex. doesn't use the notification type to produce the notification sound) If so, it should be solved in app side.

Cool, that's what I figured, Alastor. Thanks for looking at this!

Also adding Julien to check if the notification sounds for messages use the right channel type. Thanks Hema

When we don't receive the message while being in the right thread, we send a Notification and the sound actually comes from the System app's notification system. They seem to set the right audio channel in [1]. When the SMS app actually plays the sound (that's when we don't send a Notification), we use the code in [2] so I'd say we're good here. [1] https://github.com/mozilla-b2g/gaia/blob/8ff28da654e3454e907bf7d996c614f5d6267fdc/apps/system/js/notification_screen.js#L565-L570 [2] https://github.com/mozilla-b2g/gaia/blob/dbf445e5d21cb33b9925a5fed96775edb732ae6e/apps/sms/views/shared/js/notify.js#L58

(In reply to Ram Dayal Vaishnav [:ramd] from comment #0) > 4. As soon as notification comes (and notification sound plays) music stops. Few more observations about this step of STR- 1. If I take screen shot (which will also play notification sound), this bug is NOT reproducible. 2. For this step I also tried this - locked phone & unlocked (I have unlock-screen sound enabled from setting) and I can see this bug. For Step 5, please note, the music does not pause completely - as it starts playing it again as soon as we open or swipe to the music app (we need not to click on play button).

I cannot reproduce this bug. Played music via loudspeaker, went to another app, used another device to send SMS to device under test, alert sounds when SMS came in, and music resumed playing after alert sound. Tried with screen on and off. Repro rate is 0 out of 5. No repro on: Device: Flame 2.6 Master BuildID: 20151104030208 Gaia: 47da49f8206788d70d834c3a63d9245d50c89103 Gecko: 6077f51254c69a1e14e1b61acba4af451bf1783e Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 45.0a1 (2.6) Firmware Version: v18Dv4 User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

This is not reproducible from SMS notification sound. Please try unlock sound as I mentioned in my last comment. By the way I also noticed that this is reproducible from notification sound of Loqui IM app.

Okay, I did reproduce with unlock sound enabled. I'm changing the title to better reflect this bug. STR: 1) Go to Settings > Sound, and check 'Unlock screen'. Also make sure lockscreen is enabled. 2) Go to Music app and start playing any song (does not matter if it's through loudspeaker or headphone) 3) Return to Homescreen or any screen as long as it's not looking at Music app after next step 4) Lock phone, and unlock it Expected: Music automatically resumes playing after the unlock sound is played Actual: Music completely stops as soon as the unlock sound is played Repro rate: 5/5 Attaching a logcat in next comment. Device: Flame 2.6 Master BuildID: 20151105030203 Gaia: 607b9c5db7fdbbafc16a572e7c319baa266a3372 Gecko: 59c648a3f95524cb1ee42f2306c1db2698d35258 Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 45.0a1 (2.6) Firmware Version: v18Dv4 User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 I'm seeing another issue on Aries where music stops altogether as soon as user returns to Home. Investigating that one.

Is this a regression?

(In reply to Jayme Mercado [:JMercado] from comment #12) > Is this a regression? Yes, this is a regression from Flame 2.2. 2.5 is affected: Device: Flame 2.5 BuildID: 20151105004500 Gaia: 47da49f8206788d70d834c3a63d9245d50c89103 Gecko: 5c9fd135d4309239794126f1942d6e7aa8b3579c Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 44.0 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 2.2 is unaffected. Music plays along with unlock sound and continues to play afterwards. Device: Flame 2.2 BuildID: 20151105032504 Gaia: 885647d92208fb67574ced44004ab2f29d23cb45 Gecko: 9d91dfad5e16 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 ---- And Aries is also affected using yesterday's build. (on latest this can't be tested due to bug 1222143) Device: Aries 2.6 BuildID: 20151104121537 Gaia: 47da49f8206788d70d834c3a63d9245d50c89103 Gecko: 6077f51254c69a1e14e1b61acba4af451bf1783e Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 45.0a1 (2.6) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Let's get a window here then.

b2g-inbound regression window: Last Working Device: Flame 2.5 BuildID: 20151020014909 Gaia: f95dbdf32ef1d9520022e11415947d4beff08b0f Gecko: b3882ed5ba7a11dc9049048e094a9cb53f15503d Version: 44.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 First Broken Device: Flame 2.5 BuildID: 20151020021908 Gaia: d3becb4a5dfd01f3b150b6c52a2afb1e7a129819 Gecko: bab3e830f65d7466df7f4e0ee90615425a2d47fb Version: 44.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Last Working Gaia First Broken Gecko - no repro Gaia: f95dbdf32ef1d9520022e11415947d4beff08b0f Gecko: bab3e830f65d7466df7f4e0ee90615425a2d47fb Last Working Gecko First Broken Gaia - repro Gaia: d3becb4a5dfd01f3b150b6c52a2afb1e7a129819 Gecko: b3882ed5ba7a11dc9049048e094a9cb53f15503d Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/f95dbdf32ef1d9520022e11415947d4beff08b0f...d3becb4a5dfd01f3b150b6c52a2afb1e7a129819 Caused by changes made in Bug 1180618.

Evan the changes for bug 1180618 seem to have caused this issue. Can you please take a look?

It seems that the audio competing policy is incorrect, we should resume the "content" after "normal".

This is not a duplicate of Bug 1222300. See the reason in [1]. The root cause is that normal audio channel will interrupt content audio channel. And the content audio channel will not be resumed. The rules are defined in the spec[2]. To fix this, we should use "system" audio channel type in lockscreen. For example, we should do `unlockAudio.mozAudioChannelType = 'system';` in the [3] file. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1222300#c3 [2]: https://bug1068219.bmoattachments.org/attachment.cgi?id=8579177#12 [3]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/lockscreen/js/lockscreen.js#L525-L528

Added patch to fix it.

Comment on attachment 8686515 [details] [gaia] evanxd:bug-1214908 > mozilla-b2g:master Hi Greg, Could you review the patch? Thanks.

Comment on attachment 8686515 [details] [gaia] evanxd:bug-1214908 > mozilla-b2g:master Well, since the landing policy, could you add one unit test for that and set review again? The code looks good but we need the test, thanks.

Updated patch to add tests: https://github.com/evanxd/gaia/commit/e5596fce47dbb608523ea1016e7232768d4964ff

Comment on attachment 8686515 [details] [gaia] evanxd:bug-1214908 > mozilla-b2g:master Hi Greg, I added a test. Could you review the patch again? Thanks.

Comment on attachment 8686515 [details] [gaia] evanxd:bug-1214908 > mozilla-b2g:master It's okay now. Thanks.

Greg, thanks for the review.

master: https://github.com/mozilla-b2g/gaia/commit/70a40201c4cd67e5ea0f89db3e80c27f7270afc3