[GitHub issue by timdream on 2012-09-18T08:07:27Z, https://github.com/mozilla-b2g/gaia/issues/4847] STR: 1. turn the volume all the way down to mute the phone 2. Set an alarm in clock, wait for the alarm Expected: 1. Hear the alarm sound Actual: 1. Doesn't hear the alarm sound Note: As discussed in dev-b2g, we need some kind attribute or pref to bypass the master volume mute for this kind of sound. If we cannot do it then Clock app need to unmute the master volume and restore it's value later.

[GitHub comment by timdream on 2012-09-18T08:08:28Z] Add `needGeckoSupport`. Remove if we are not going to rely on special attribute for v1.

[GitHub comment by autonome on 2012-09-24T15:47:46Z] Blocking. You should hear the alarm sound. Or the alarm is useless.

If 791642 lands, we would have `audio.volume.alarm` for setting alarm volume, separated from other type of volume.

(In reply to Alive Kuo [:alive] from comment #3) > If 791642 lands, we would have `audio.volume.alarm` for setting alarm > volume, separated from other type of volume. I am not sure that's correct. How do I tell Gecko, just by using <audio>, that the sound from that <audio> element is an alarm rather a sound?

I think this bug is depend on Bug 795237 not 791642.

[mass adding reproducible keyword for any open Gaia bug with the word "STR:" in comments]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #4) > (In reply to Alive Kuo [:alive] from comment #3) > > If 791642 lands, we would have `audio.volume.alarm` for setting alarm > > volume, separated from other type of volume. > > I am not sure that's correct. How do I tell Gecko, just by using <audio>, > that the sound from that <audio> element is an alarm rather a sound? This is a particularly interesting question. CC'ing mwu and cjones to check if they have any ideas?

There's no way to set volume per-stream/app. Unless Matthew has better ideas, I think the best we'll be able to do is temporarily unmute if we're muted.

Please refer to bug 795237 (depends on) which discussed to add parameter of audio stream type into related audio Web API. So bug 791642 have change to add more volume control on stream types.

(In reply to dscravaglieri from comment #10) > > *** This bug has been marked as a duplicate of bug 796628 *** No, there are not duplicates. Music and alarm are of different stream type.

This one seems a duplicate with bug 800651, where the root cause can be traced back to bug 788204.

(In reply to Gene Lian [:gene] from comment #12) > This one seems a duplicate with bug 800651, where the root cause can be > traced back to bug 788204. I think it is not a duplicated issue. We need to let alarm sound in mute mode. If alarm don't sound in mute mode, how the user know the alarm goes off?

(In reply to Ian Liu [:ianliu] from comment #13) > (In reply to Gene Lian [:gene] from comment #12) > > This one seems a duplicate with bug 800651, where the root cause can be > > traced back to bug 788204. > > I think it is not a duplicated issue. > We need to let alarm sound in mute mode. > If alarm don't sound in mute mode, how the user know the alarm goes off? Thanks Ian for the clarification! Some questions: 1. Why we need to let alarm sound in mute mode? Personally, if I set my mobile to mute mode, I don't expect it will shock me with any voice, including alarm. 2. If we really want to let the alarm sound in mute mode, is that possible for the Gaia end to use any existing APIs to temporally turn off the mute mode to fire alarm?

I agree with gene. if you're in a movie theater or some place like the library or a meeting, you don't want the alarm to make a noise.

(In reply to Gene Lian [:gene] from comment #14) > (In reply to Ian Liu [:ianliu] from comment #13) > > (In reply to Gene Lian [:gene] from comment #12) > > > This one seems a duplicate with bug 800651, where the root cause can be > > > traced back to bug 788204. > > > > I think it is not a duplicated issue. > > We need to let alarm sound in mute mode. > > If alarm don't sound in mute mode, how the user know the alarm goes off? > > Thanks Ian for the clarification! Some questions: > > 1. Why we need to let alarm sound in mute mode? Personally, if I set my > mobile to mute mode, I don't expect it will shock me with any voice, > including alarm. > I have checked the behavior in iPhone and Android. They will let alarm sound in mute mode. Personally, I like to let alarm sound in mute mode. I usually forget to turn the mute mode OFF. It will let me can not heard my set alarm. But, I agree that we don't want the alarm to make a noise in library or a meeting. I think we need UX's help to define what the behavior is going to be. So, add jcarpenter in mail list. > 2. If we really want to let the alarm sound in mute mode, is that possible > for the Gaia end to use any existing APIs to temporally turn off the mute > mode to fire alarm? For this solution, I don't think Clock APP should control system volume. It sound like a work around. According comment 3, we need to use `audio.volume.alarm` for setting alarm volume.

Josh, please see comment 15 and comment 16.

Asking Casey and Larissa to comment here, as they've both worked on sound issues.

(In reply to Ian Liu [:ianliu] from comment #16) > Personally, I like to let alarm sound in mute mode. > I usually forget to turn the mute mode OFF. > It will let me can not heard my set alarm. > But, I agree that we don't want the alarm to make a noise in library or a > meeting. I think you might want to set your phone to mute when going to sleep and still be woken up by the alarm (esp. as AFAIK we don't support alarms when the phone is off, like Nokia does at least on Symbian and feature phones). On my N9, I have a "(no sound)" option when selecting the sounds for a particular alarm, and I guess it might vibrate in that case (though I haven't checked).

If I set my phone to mute, I expect it to be quite until I turn the mute toggle OFF. If I miss my alarm, it's my fault since I explicitly set the phone to mute. I would be pretty annoyed if my alarm was to go off at 8pm in the middle of a movie during a quite part after accidentally thinking i had set it for 8am in the morning. If the phone is set to mute, we can still have the alarm vibrate the phone. It would also be important that the user could easily tell that the phone mute is set to ON. That said, I think it would be useful to provide the user with a setting to allow for alarms to sound while the phone is set to mute, but in the absence of this I would say that Mute should be just that -- Muted.

I should have also mentioned that there is one other option, which is to add a "silent" mode. Though I would consider this as new functionality. Also, it may be confusing to some the difference between "Mute" and "Silent".

(In reply to Casey Yee [:cyee] from comment #21) > I should have also mentioned that there is one other option, which is to add > a "silent" mode. Though I would consider this as new functionality. Also, > it may be confusing to some the difference between "Mute" and "Silent". Adding functionality is too late in the game. (In reply to Casey Yee [:cyee] from comment #20) > If I set my phone to mute, I expect it to be quite until I turn the mute > toggle OFF. If I miss my alarm, it's my fault since I explicitly set the > phone to mute. > > I would be pretty annoyed if my alarm was to go off at 8pm in the middle of > a movie during a quite part after accidentally thinking i had set it for 8am > in the morning. > > If the phone is set to mute, we can still have the alarm vibrate the phone. > It would also be important that the user could easily tell that the phone > mute is set to ON. If you stand by what you said, and defined v1 phone functionality as said, please RESOLVED INVALID this bug. Thanks.

I'm sorry for not responding to this bug earlier, as I was not on the CC list and didn't hear about it until now. I feel strongly that the user should be notified of an alarm, even when the phone is muted. I think the alarm function has a higher priority than the silent mode function for the following reasons: 1. The purpose of an alarm is to warn the user of events that they find so important that they're willing to be interrupted. Alarms are loud and repetitive to make sure that the user hears them. This function is crucial when the user has set an alarm to wake him up, or an alarm to make sure he doesn't miss his flight, or one for taking medicine. Even if the user has forgotten that he's set his alarm, the alarm _has to ring_, because the main point of having one is to remind the user of something important. There are other, more lightweight ways that the user can set reminders for himself that a silent mode can potentially override, but the alarm should not be one of them, and we should stay consistent to this metaphor. 2. The use cases in which an alarm unnecessarily disrupts an event are likely to be rare. What I mean by "unnecessarily" are cases in which the alarm's interruption is unwanted because the user doesn't plan on paying attention to it anyway. One example is the movie theater use case because the user plans to disregard the alarm anyway because he's busy watching the movie. However, these cases are fairly rare. Most of the time, the alarm goes off because the user wants the reminder, not because he has forgotten about an alarm that he doesn't want anymore. Yes, the alarm might disrupt the user every so often, but we shouldn't design for this case because there are more circumstances in which the user wants a feature that will interrupt him. Besides, if he wants to make absolute sure that he isn't disrupted, he can simply turn the phone off. A few more points to the design: 1. This should only apply to the clock alarm. If my phone is on silent, I don't want to hear any notifications about calendar events, reminders, tasks, etc. silent mode trumps these things. 2. This should only apply to alarms I've set for myself. No app or remote person should be able to set an interruptive alarm for me. 3. I tossed around the idea of having the alarm vibrate instead when the phone is on silent mode, but I think that wouldn't really help alert the user in case he was sleeping. So I think it will have to be an auditory alarm. 4. The alarm should be easily disabled by pressing a hardware button (in the same way the user can mute a phone call) or tapping the screen. This way, if there are cases in which the user has made a mistake in setting an alarm, it can easily be corrected. 5. The alarm should expire after a brief period of time so that it's not super annoying and battery-draining. It shouldn't keep recurring (a.k.a. snooze function) unless the user has specifically asked it to.

We can follow and reference the proposal with the link: https://docs.google.com/file/d/0B0OE-RhDvDNvUW9kdEpDcERUSDA/edit?pli=1

We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule). If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

(In reply to Larissa Co from comment #23) > I'm sorry for not responding to this bug earlier, as I was not on the CC > list and didn't hear about it until now. > > I feel strongly that the user should be notified of an alarm, even when the > phone is muted. I think the alarm function has a higher priority than the > silent mode function for the following reasons: > > 1. The purpose of an alarm is to warn the user of events that they find so > important that they're willing to be interrupted. > > Alarms are loud and repetitive to make sure that the user hears them. This > function is crucial when the user has set an alarm to wake him up, or an > alarm to make sure he doesn't miss his flight, or one for taking medicine. > Even if the user has forgotten that he's set his alarm, the alarm _has to > ring_, because the main point of having one is to remind the user of > something important. > > There are other, more lightweight ways that the user can set reminders for > himself that a silent mode can potentially override, but the alarm should > not be one of them, and we should stay consistent to this metaphor. > > > 2. The use cases in which an alarm unnecessarily disrupts an event are > likely to be rare. > > What I mean by "unnecessarily" are cases in which the alarm's interruption > is unwanted because the user doesn't plan on paying attention to it anyway. > One example is the movie theater use case because the user plans to > disregard the alarm anyway because he's busy watching the movie. However, > these cases are fairly rare. Most of the time, the alarm goes off because > the user wants the reminder, not because he has forgotten about an alarm > that he doesn't want anymore. > > Yes, the alarm might disrupt the user every so often, but we shouldn't > design for this case because there are more circumstances in which the user > wants a feature that will interrupt him. Besides, if he wants to make > absolute sure that he isn't disrupted, he can simply turn the phone off. > > > A few more points to the design: > > 1. This should only apply to the clock alarm. If my phone is on silent, I > don't want to hear any notifications about calendar events, reminders, > tasks, etc. silent mode trumps these things. > 2. This should only apply to alarms I've set for myself. No app or remote > person should be able to set an interruptive alarm for me. > 3. I tossed around the idea of having the alarm vibrate instead when the > phone is on silent mode, but I think that wouldn't really help alert the > user in case he was sleeping. So I think it will have to be an auditory > alarm. > 4. The alarm should be easily disabled by pressing a hardware button (in the > same way the user can mute a phone call) or tapping the screen. This way, if > there are cases in which the user has made a mistake in setting an alarm, it > can easily be corrected. > 5. The alarm should expire after a brief period of time so that it's not > super annoying and battery-draining. It shouldn't keep recurring (a.k.a. > snooze function) unless the user has specifically asked it to. Hi Larrisa, 1.2. I think we couldn't know an alarm is set by the user or by the calendar now. An app with alarm permission could do that. 3. Do we need to restrict the volume of the alarm to a fixed value? I do think so. 4. Use hardware button to close attention screen(alarm) is possible. But we might deal with this carefully. Shouldn't close a callscreen when it's connected(on a call). 5. This is alarm's spec so Ian would have some idea on this.

Depends on: 796658

Because 796658 landed, this bug has a quick fix now: The alarm channel is different from other channel now, The only way to mute the alarm NOW is go to the settings app to adjust the volume of alarm sound. Press the volume rockers isn't relevant to alarm volume anymore.

Reopen. Although 796658 is landed and the alarm audio's channel type is set to 'alarm', but it seems gecko doesn't really treat the audio as alarm channel. But no exception got. Should be a gecko bug.

I tested alarm app with the version as below. And I can be noticed that volume from firing alarm is adjustable by alarm volume bar in setting app. gaia: 8b2ff150687e58845ae3dd44e729c8f1a0532a16 gecko: b373a990966ae6b2fab0e8d4db9a6fb9f2388eca Could you confirm this or what is the version you tested? Thanks.

I cannot reproduce with latest gecko, closing.

verified in unagi daily build. build info 2012-11-21 gaia : 7967ee63b77b537562d524242fe4f9dc881a39ea releases/gecko : 372f36fb1a5d6428bcba336499abe5c2d0105433 gonk-misc : aafa9ca4d2e9e755fe9964018a9797eac4ecc7de