355 bytes, text/html
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
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?
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.
Triage: BB+, P1 for feature not working under common use scenario
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C3 (12dec-1jan)
Comment on attachment 690746 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6937 https://github.com/mozilla-b2g/gaia/commit/b700e38a7eb88c8cc083b93ed203f4ad3a904dc1
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
verified on 2012-12-12 unagi daily build build info: releases/gaia : db435724709181ffa3348c06cfcc80b71375e73d releases/gecko : 8e66dde61aec02ba5a4a4e44583679aedc609a73
Status: RESOLVED → VERIFIED
Duplicate of this bug: 821949
You need to log in before you can comment on or make changes to this bug.