Closed Bug 1214908 Opened 9 years ago Closed 8 years ago

music stops due to screen unlock sound

Categories

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

defect
Not set
normal

Tracking

(b2g-v2.2 unaffected, b2g-v2.5 affected, b2g-master affected)

RESOLVED FIXED
Tracking Status
b2g-v2.2 --- unaffected
b2g-v2.5 --- affected
b2g-master --- affected

People

(Reporter: ram, Assigned: evanxd)

References

Details

(Keywords: foxfood, regression, Whiteboard: [bzlite])

Attachments

(2 files)

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
Flags: needinfo?(hkoka)
This doesn't sound right, but it's probably an audio channel issue. The music app doesn't have any direct control over this.
Component: Gaia::Feedback → AudioChannel
Keywords: qawanted
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
Flags: needinfo?(hkoka) → needinfo?(felash)
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
Flags: needinfo?(felash)
(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
Flags: needinfo?(jmercado)
Flags: needinfo?(jmercado)
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
Summary: music stops due to notification sound → music stops due to screen unlock sound
Is this a regression?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
(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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawantedregression
Let's get a window here then.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng
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.
Blocks: 1180618
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Evan the changes for bug 1180618 seem to have caused this issue.  Can you please take a look?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(evan)
It seems that the audio competing policy is incorrect, we should resume the "content" after "normal".
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Flags: needinfo?(evan)
Resolution: DUPLICATE → ---
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
Component: AudioChannel → Gaia::System::Lockscreen
Added patch to fix it.
Comment on attachment 8686515 [details] [review]
[gaia] evanxd:bug-1214908 > mozilla-b2g:master

Hi Greg,

Could you review the patch?

Thanks.
Attachment #8686515 - Flags: review?(gweng)
Assignee: nobody → evan
Comment on attachment 8686515 [details] [review]
[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.
Attachment #8686515 - Flags: review?(gweng)
Comment on attachment 8686515 [details] [review]
[gaia] evanxd:bug-1214908 > mozilla-b2g:master

Hi Greg,

I added a test.
Could you review the patch again?

Thanks.
Attachment #8686515 - Flags: review?(gweng)
Comment on attachment 8686515 [details] [review]
[gaia] evanxd:bug-1214908 > mozilla-b2g:master

It's okay now. Thanks.
Attachment #8686515 - Flags: review?(gweng) → review+
Greg, thanks for the review.
master: https://github.com/mozilla-b2g/gaia/commit/70a40201c4cd67e5ea0f89db3e80c27f7270afc3
Status: REOPENED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.