[Clock] No alarm sound when wake up from suspend

VERIFIED FIXED in B2G C3 (12dec-1jan)

Status

Firefox OS
Gaia::Clock
P1
normal
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: kanru, Assigned: iliu@mozilla.com, ianliu.moz@gmail.com)

Tracking

unspecified
B2G C3 (12dec-1jan)
All
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [target:12/21])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
On the dogfooding phone, if the alarm goes off while the phone was suspended, I cannot hear the alarm sound.

Steps to reproduce:

 1. Set the alarm to one minute later
 2. Turn off screen
 3. Wait

Actual result:

 The screen turned back on, but no alarm sound

Expected result:

 I can hear alarm sound
(Reporter)

Updated

5 years ago
blocking-basecamp: --- → ?
I can also reproduce this bug recently. The alarms can fire and vibrate with the attention screen but has no sound. Not sure if it is related to what we've done for the audio channels things recently.

Alive and Ian, any comments?
(In reply to Gene Lian [:gene] from comment #1)
> I can also reproduce this bug recently. The alarms can fire and vibrate with
> the attention screen but has no sound. Not sure if it is related to what
> we've done for the audio channels things recently.
> 
> Alive and Ian, any comments?

My guess is permission check. The alarm channel works fine when you are in the clock app to preview an alarm. Nothing bad happens. But the same channel in attention screen fails. I wonder the opened window doesn't have permission to use alarm channel but this is only a frontend-er's assumption. Ping mchen and rlin.
I also can reproduce the issue in screen on mode. Even if, we don't set mozAudioChannelType = 'alarm'. It should be a blocking issue. Do mchen and rlin have any idea?

Comment 4

5 years ago
Hi all,

Please refer to the log as below.
1. The alarm sound passed the permission checking.
2. The alarm sound called play().
3. The second number after UpdateAudioChannelPlayingState means the ready state from media element and it always show HAVE_NOTHING during the play state.

So I think this is not related to the audio channel service because it didn't be triggered yet. And could Gaia member help to check your file URI is correct or not? Thanks.

E/Gecko - SYDNEY_AUDIO(  572): UpdateAudioChannelPlayingState 0 0 0 1
E/Gecko - SYDNEY_AUDIO(  572): mozaudiochannel: 3
E/Gecko - SYDNEY_AUDIO(  572): CheckAudioChannelPermissions alarm
E/Gecko - SYDNEY_AUDIO(  572): ok
E/Gecko - SYDNEY_AUDIO(  572): UpdateAudioChannelPlayingState 0 0 0 1
E/Gecko - SYDNEY_AUDIO(  572): play
E/Gecko - SYDNEY_AUDIO(  572): UpdateAudioChannelPlayingState 0 0 1 1

By the way the preview sound also assigned as alarm channel and it worked well (also it can mute the content channel well).
Thanks for Marco's verified experiment.

I try to check previous version without Bug 807431 - [Phone] Final Ringtones Need to be Added to the Build.
There is an incorrect file path with 'shared/ringtones/media/alarms/' in Gaia side.
https://github.com/mozilla-b2g/gaia/blob/master/apps/clock/js/onring.js#L79
It should be 'shared/resources/media/alarms/'.
I'll take care the issue.
Assignee: nobody → iliu
Created attachment 690746 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6937

Pointer to Github pull-request
Comment on attachment 690746 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6937

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Some nit comes from Bug 807431
User impact if declined: Cannot hear ringtone when alarm goes off.
Testing completed: 
Risk to taking this patch (and alternatives if risky): None.

Fix a nit in the file path of onring's ringtone.
Change 'ringtones' to be 'resources'.
I think Vivien could help to review the patch.
Attachment #690746 - Flags: review?(21)
Attachment #690746 - Flags: approval-gaia-master?(21)
Triage: BB+, P1 for feature not working under common use scenario
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C3 (12dec-1jan)
Whiteboard: [target:12/21]
Can this be closed now?
Since the pr(https://github.com/mozilla-b2g/gaia/pull/6937) is merged, we can close the issue now.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 12

5 years ago
verified on 2012-12-12 unagi daily build
build info:
releases/gaia : db435724709181ffa3348c06cfcc80b71375e73d
releases/gecko : 8e66dde61aec02ba5a4a4e44583679aedc609a73
Status: RESOLVED → VERIFIED
(Assignee)

Updated

5 years ago
Duplicate of this bug: 821949

Updated

5 years ago
Duplicate of this bug: 822939
You need to log in before you can comment on or make changes to this bug.