819842 - [Sound Manager] Silent mode

Status: RESOLVED FIXED

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

Description

[(inactive after 6/18) Alive Kuo [:alive]]

This is follow up from bug 810780 's slient mode discussion.

Dev Story:
we have multi-channel now and we want to mute 2 channels easily by volume rocker.

Use case:
Silencing all streams in this mode was to give the user
confidence that his phone will really, truly not ring when he's in that
important meeting. (Bug 810780 #28) (I am confident except for alarm, by UX design)

Spec:
http://people.mozilla.com/~lco/FFOS/Sound/

Dev Proposal:
We have 4 channels visible to the user now, 
1. telephony
2. content
3. notification
4. alarm

So, the problem would be how to change keep content and notification channel fall into the same mute state when one of them is muted.

My thought: add `mute.enabled` to settings, triggered by:
1. Set by anyone of volume of content/notification down to 0(with rockers or settings app)
2. Reboot (Unset, to unmute mode)
3. UnSet by anyone of content/notification from 0 to 1+
*1. and 3. are just like `vibration.enabled` set in sound manager.

This needs addition gecko work to listen to this setting in gecko's audio service. If the mute is on then gecko would ignore the value of audio.volume.content and audio.volume.notification

Jonas, Larrisa, Marco, does this make sense to you?

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

BB+, P1 - pending feature work

Comment 2

[Marco Chen [:mchen]]

From my point of view, I would like to just mute one of content or notification but no all of them. So I want to keep the design now.

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

Below is page.7 of the spec.

> Toggling the rocker adjusts both the ring and notifications volume 
> (from lowest to highest):
> • Silent Mode (Volume 0)
> • Silent + Vibrate Mode (Volume 0)
> • Volume levels 1 - 10
> On Vibrate and Silent modes, other sounds (keypress, camera 
> shutter, screen unlock) are also inactive.
> On Vibrate and Silent modes, Content Volume is also muted by 
> default. However, the user can override the content volume when 
> content is actively playing without changing the mode.  For example, 
> if the user starts playing a video while in Silent Mode, there won't be 
> any sound. If he adjusts the volume, he will hear sound for that 
> content only until he exits the app. Once he exits the app, his phone 
> remains in Silent Mode.

This design may conflict against our audio competing policy brought by bug 805333. What would happen to an app fall into background and then back to foreground while in silent mode?
I think mostly this is gecko work and may introduce some regression about accidentally mute or unmute something. renominating. This should not be blocking.

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

BB- as the LOE is M and it doesn't seem exactly neccesary to mute Ringer / Notification and Content at the same time. 
Please renominate if this is not acceptable user experience.

Comment 5

[Josh Carpenter [:jcarpenter]]

I'm deferring to Casey, who is main contact for audio UX.

Comment 6

[Larissa Co [:lco]]

As I mentioned on bug 810780:

If this is not feasible for v1, that's ok. So basically for v1, the content volume will still remain whatever it is when it's in Silent Mode, but ringer and notifications will be muted, right?

Comment 7

[Larissa Co [:lco]]

Sorry, scrap that comment for now. I just read Jonas' email with the following comment:

* The use-case for a silent mode makes a lot of sense to me. I.e.
wanting to be sure that the phone won't suddenly start making a sound
seems very important. Even when interacting with the phone. I.e. if
the user is sitting on a bus or in a meeting and doesn't want to
disturb people around him/her, he/she should be able to interact with
the phone without worrying that it will start making sound.

I'm going to read his entire email and consider his points first.

Comment 8

[Larissa Co [:lco]]

Here's my proposal, let me know if it's technically feasible:

4 audio streams:
* ringer + notifications
* alarm
* content
* telephony

By pressing the volume down button to 0 during normal (non-call, non-content) operation, the user enters *silent mode*:
* The ringer is set to 0
* Vibrate is temporarily set to always true (volume down one more step turns vibrate off)
* Content is set to 0
* Alarm and Telephony volumes don't change

While in *silent mode*, content volume is off until the user adjusts volume (while playing content). Once the user adjusts content volume:
* Content volume level stays the same regardless of the app/content playing
* ringer volume is still 0
* Vibrate is still true (until the user adjusts the ringer volume)
* Alarm and Telephony volumes don't change

When the user gets out of *silent mode* by increasing the ringer volume to 1:
* Ringer is set to n>0
* Vibration goes back to state in ring mode (whether on or off)
* Content volume maintains whatever state it was in (whether 0 or another value)
* Alarm and Telephony volumes don't change

Notes:
In this proposal, I'm trying to balance the desire to preserve the intent of silent mode by silencing content when the user first enters that mode. However, I'm also allowing the user to override it by increasing the volume while playing content.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If I understand the proposal correctly, is the following how it should work:

When pressing the volume-down button:
1. If audio is currently playing, adjust the volume for that channel down.
2. If there is no audio playing, adjust the volume for the "ringer/notification" channel down.
3. If we just adjusted the volume for "ringer/notification" down, and we reached volume 0, go into silent mode. When going into silent mode store away the current "content" volume and then set the "content" volume to 0. Do not change the volume for "alarm" or "telephony".

When pressing the volume-up button:
1. If audio is currently playing, adjust the volume for that channel up.
2. If there is no audio playing, adjust the volume for the "ringer/notification" channel up.
3. If we are in silent mode and adjusted the volume for "content" up, forget about the stored-away "content" volume.
4. If we are in silent mode and adjusted the volume for "ringer/notification" also restore the "content" volume if we still have a stored-away value for it.


That sounds quite doable to me, though it's up to Alive.


Alive: Regarding where to store the "previous" content volume when we go into silent mode. We can always store it in a new setting. Another alternative is to store it in any indexedDB database in the system app. Either is fine with me.

If we are using settings to control vibrate mode, then we can use the same method for remembering the previous vibrate mode when going into silent mode.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

feedback+ with something addressed.

(In reply to Larissa Co from comment #8)
> Here's my proposal, let me know if it's technically feasible:
> 
> 4 audio streams:
> * ringer + notifications
> * alarm
> * content
> * telephony
> 
> By pressing the volume down button to 0 during normal (non-call,
> non-content) operation, the user enters *silent mode*:
> * The ringer is set to 0
> * Vibrate is temporarily set to always true (volume down one more step turns
> vibrate off)

Vibration behavior now:
* Set to true when first time the volume (of notification channel) is hit 0 by volume-down.
* Set to false when second time the user presses the volume-down key.
* Do nothing when the user presses volume-up anytime. (Remain the same state).

I don't know what does 'temporarily' here means. But maybe current behavior is just you want?

> * Content is set to 0
> * Alarm and Telephony volumes don't change
> 
> While in *silent mode*, content volume is off until the user adjusts volume
> (while playing content). Once the user adjusts content volume:
> * Content volume level stays the same regardless of the app/content playing
> * ringer volume is still 0
> * Vibrate is still true (until the user adjusts the ringer volume)
> * Alarm and Telephony volumes don't change
> 
> When the user gets out of *silent mode* by increasing the ringer volume to 1:
> * Ringer is set to n>0
> * Vibration goes back to state in ring mode (whether on or off)
> * Content volume maintains whatever state it was in (whether 0 or another
> value)
> * Alarm and Telephony volumes don't change
> 
> Notes:
> In this proposal, I'm trying to balance the desire to preserve the intent of
> silent mode by silencing content when the user first enters that mode.
> However, I'm also allowing the user to override it by increasing the volume
> while playing content.

So the key to enter silent mode is 'hit volume rocker to meet 0 in notification channel'. If the user uses volume key when content is playing to meet 0 volume, this is not really silent mode, right?

If so, this proposal all looks good to me.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jonas Sicking (:sicking) from comment #9)
> If I understand the proposal correctly, is the following how it should work:

I have the same thought except for stored content volume.

> Alive: Regarding where to store the "previous" content volume when we go
> into silent mode. We can always store it in a new setting. Another
> alternative is to store it in any indexedDB database in the system app.
> Either is fine with me.

I don't think that to create another setting for the same volume setting is an elegant way...I hope my reviewer would accept this. IndexedDB sounds a better idea than another settings.

I wonder this volume may be polluted by some reason I don't know. But workaround here is to check the value stored first before set it back so you are right.

Another thing worthy to be considered is mute policy of our audio competing. But now pause already replaces mute so I think there's no doubt here.

> 
> If we are using settings to control vibrate mode, then we can use the same
> method for remembering the previous vibrate mode when going into silent mode.

Fine to me.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

The spec now is implementable than before. Only gaia change needed. Renominate for bb?

User impact: Because content volume is not controllable from settings app now, the only way to mute content+normal+ringer+notification together is to press volume down key first to let notification channel to reach 0 and then play a song and then press again volume down key to reach 0 so you will get a silent phone.
This is also related to DTMF tone silence because it now is content channel.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Regarding using settings or IndexedDB, I don't have a strong opinion. I agree with you that using IndexedDB is cleaner. However one problem is that there are two apps involved here. The settings app and the system app. If both of them needs to access this temporary storage, then you can't use IndexedDB since IndexedDB data isn't shared between apps.

So it's entirely up to you which solution to use. But it might depend on the technical requirements which solutions will work.


(In reply to Alive Kuo [:alive] from comment #10)
> > 4 audio streams:
> > * ringer + notifications
> > * alarm
> > * content
> > * telephony
> > 
> > By pressing the volume down button to 0 during normal (non-call,
> > non-content) operation, the user enters *silent mode*:
> > * The ringer is set to 0
> > * Vibrate is temporarily set to always true (volume down one more step turns
> > vibrate off)
> 
> Vibration behavior now:
> * Set to true when first time the volume (of notification channel) is hit 0
> by volume-down.
> * Set to false when second time the user presses the volume-down key.
> * Do nothing when the user presses volume-up anytime. (Remain the same
> state).
> 
> I don't know what does 'temporarily' here means. But maybe current behavior
> is just you want?

I think the idea is something like this:

There is a setting which controls "vibration enabled". When this setting is true, incoming notifications and phone calls vibrate as well as play audio.

There are two things that control this setting: A checkbox in the settings app, and volume controls. If we don't have such a checkbox, please disregard all of the below and we need to come up with some other plan :)

When we are not in silent mode, the "vibration enabled" setting is entirely controlled by the checkbox in the settings app. If the checkbox is checked, we enable vibration, if the checkbox is not checked we disable vibration.

However if the user presses the volume down button such that we enter silent mode, we override the settings checkbox and always enable "vibration enabled". This is the "temporary on" thing. The checkbox in the settings UI is not affected by this however.

If the user presses the volume down again, when we are in the silent mode with vibration "temporary on" it's a bit unclear what the proposal is.

I know some phones disable vibration entirely in this situation. I think this is a bad idea since it means that if you repeatedly press the volume down button, you can easily end up entirely disabling any notification about incoming phone calls.

What I propose is:

When we enter silent mode, set temporary enable "vibration enabled" no matter what the checkbox in the settings UI says.

If the user presses volume down again, and the checkbox in the settings UI is checked, don't do anything. I.e. vibration still stays on.

If the user presses volume down again, and the checkbox in the settings UI is *not* checked, disable vibration again.

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jonas Sicking (:sicking) from comment #13)
> Regarding using settings or IndexedDB, I don't have a strong opinion. I
> agree with you that using IndexedDB is cleaner. However one problem is that
> there are two apps involved here. The settings app and the system app. If
> both of them needs to access this temporary storage, then you can't use
> IndexedDB since IndexedDB data isn't shared between apps.

Gosh, you are right :(
So the key to this is
A) Only apply this rule(silent mode) to volume key action.
B) Apply to whole apps who touches settings of volume. You need to write the same logic twice or more times.

I personally vote for A).

> 
> So it's entirely up to you which solution to use. But it might depend on the
> technical requirements which solutions will work.
> 
> 
> (In reply to Alive Kuo [:alive] from comment #10)
> > > 4 audio streams:
> > > * ringer + notifications
> > > * alarm
> > > * content
> > > * telephony
> > > 
> > > By pressing the volume down button to 0 during normal (non-call,
> > > non-content) operation, the user enters *silent mode*:
> > > * The ringer is set to 0
> > > * Vibrate is temporarily set to always true (volume down one more step turns
> > > vibrate off)
> > 
> > Vibration behavior now:
> > * Set to true when first time the volume (of notification channel) is hit 0
> > by volume-down.
> > * Set to false when second time the user presses the volume-down key.
> > * Do nothing when the user presses volume-up anytime. (Remain the same
> > state).
> > 
> > I don't know what does 'temporarily' here means. But maybe current behavior
> > is just you want?
> What I propose is:
> 
> When we enter silent mode, set temporary enable "vibration enabled" no
> matter what the checkbox in the settings UI says.
> 
> If the user presses volume down again, and the checkbox in the settings UI
> is checked, don't do anything. I.e. vibration still stays on.

I disagree. This implies that the checkbox UI doesn't reflect really vibration state. Confusing.

> 
> If the user presses volume down again, and the checkbox in the settings UI
> is *not* checked, disable vibration again.

If we want to restore vibration setting when volume up is pressed,
the problem is the same as silent mode volume restore. We need to write the same restore mechanism for vibration setting in both settings app and system app. Still wonder some race condition may happen.

I propose not to restore anything when volume up, just go to volume 1. for v1. If we really need this restore, do it in platform is more suitable than in gaia IMO. Use a 'silent-mode.enabled' key for that.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It seems very confusing to me if pressing the volume button down once and then up once can cause the vibration to turn on. I would expect that if you press down once and then up once (or the other way around) that you should return to whatever state you were in.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jonas Sicking (:sicking) from comment #15)
> It seems very confusing to me if pressing the volume button down once and
> then up once can cause the vibration to turn on. I would expect that if you
> press down once and then up once (or the other way around) that you should
> return to whatever state you were in.

I have no strong idea but concern. :)

I figure out what I could do here to prevent copy&paste. Let the logic of silent mode living in system app. The only thing settings app needs to do is just set 0 volume to notification channel when the user touches leftest side of the slider in settings app. When system app observes the settings of 'audio.volume.notification' goes to zero, do the save and set stuff in system app only. When the volume is changed in settings app to greater than 0, do the restore in system app when it observes the volume of notification channel is changed. The settings app is just an UI reflection of settingsDB.

This way we don't need to use another settings but could use indexedDB only in system app.

Comment 17

[Joe Cheng [:jcheng] (please needinfo)]

what's the user impact if no changes are taken at this taken? do we have a very broken UX?

Comment 18

[Larissa Co [:lco]]

(In reply to Jonas Sicking (:sicking) from comment #9)
> If I understand the proposal correctly, is the following how it should work:
> 
> When pressing the volume-down button:
> 1. If audio is currently playing, adjust the volume for that channel down.
> 2. If there is no audio playing, adjust the volume for the
> "ringer/notification" channel down.
> 3. If we just adjusted the volume for "ringer/notification" down, and we
> reached volume 0, go into silent mode. When going into silent mode store
> away the current "content" volume and then set the "content" volume to 0. Do
> not change the volume for "alarm" or "telephony".
> 
> When pressing the volume-up button:
> 1. If audio is currently playing, adjust the volume for that channel up.
> 2. If there is no audio playing, adjust the volume for the
> "ringer/notification" channel up.
> 3. If we are in silent mode and adjusted the volume for "content" up, forget
> about the stored-away "content" volume.
> 4. If we are in silent mode and adjusted the volume for
> "ringer/notification" also restore the "content" volume if we still have a
> stored-away value for it.
> 
> 
> That sounds quite doable to me, though it's up to Alive.
> 

Yup, this is an accurate description of the proposal. Actually, I didn't think it would be necessary to store/restore the old volume (point #4), but either way is fine with me :) whichever is easier. I think it's acceptable to keep content volume at 0 if the user exits silent mode but has not modified the content volume.

Comment 19

[Larissa Co [:lco]]

> > Vibration behavior now:
> > * Set to true when first time the volume (of notification channel) is hit 0
> > by volume-down.
> > * Set to false when second time the user presses the volume-down key.
> > * Do nothing when the user presses volume-up anytime. (Remain the same
> > state).
> > 
> > I don't know what does 'temporarily' here means. But maybe current behavior
> > is just you want?
> 
> I think the idea is something like this:
> 
> There is a setting which controls "vibration enabled". When this setting is
> true, incoming notifications and phone calls vibrate as well as play audio.
> 
> There are two things that control this setting: A checkbox in the settings
> app, and volume controls. If we don't have such a checkbox, please disregard
> all of the below and we need to come up with some other plan :)

Yes, there's a checkbox in the Settings App to control vibration.

> 
> When we are not in silent mode, the "vibration enabled" setting is entirely
> controlled by the checkbox in the settings app. If the checkbox is checked,
> we enable vibration, if the checkbox is not checked we disable vibration.

Correct.
> 
> However if the user presses the volume down button such that we enter silent
> mode, we override the settings checkbox and always enable "vibration
> enabled". This is the "temporary on" thing. The checkbox in the settings UI
> is not affected by this however.
> 
> If the user presses the volume down again, when we are in the silent mode
> with vibration "temporary on" it's a bit unclear what the proposal is.
> 
> I know some phones disable vibration entirely in this situation. I think
> this is a bad idea since it means that if you repeatedly press the volume
> down button, you can easily end up entirely disabling any notification about
> incoming phone calls.
> 
> What I propose is:
> 
> When we enter silent mode, set temporary enable "vibration enabled" no
> matter what the checkbox in the settings UI says.
> 
> If the user presses volume down again, and the checkbox in the settings UI
> is checked, don't do anything. I.e. vibration still stays on.
> 
> If the user presses volume down again, and the checkbox in the settings UI
> is *not* checked, disable vibration again.

I see your point about vibration states. Our initial idea was this:

1. User presses volume down to decrease volume to 1.
2. User presses volume down to 0 and enters silent mode. vibration automatically turned on (regardless of the settings checkbox)
3. User presses volume down a third time (really, this is -1). Vibration is turned off (regardless of the settings checkbox)
4. The user presses volume up (to go to 0). Vibration is turned on, but phone is still in silent mode.
5. The user presses volume up again (to go to vol 1). The phone exits silent mode. Vibration now obeys whichever setting the user has indicated in the settings app.

This being said, I think you're right in saying that this is going to be confusing to the user. I like the idea of vibration being independent of volume and only controlled by the settings app. So the revised flow would be:

1. User presses volume down to decrease volume to 1. 
2. User presses volume down to 0 and enters silent mode. Whether the phone is on vibrate or not is controlled by the Settings App.
3. User presses volume down a third time, nothing more happens. (alternate proposal would be to turn on vibrate if the user presses down a third time: this would be a temporary override to his preference in the settings app.)
4. The user presses volume up (to go to vol 1). The phone exits silent mode. Whether the phone is on vibrate or not is controlled by the Settings App.


1.

Comment 20

[Larissa Co [:lco]]

(In reply to Alive Kuo [:alive] from comment #12)
> User impact: Because content volume is not controllable from settings app
> now, the only way to mute content+normal+ringer+notification together is to
> press volume down key first to let notification channel to reach 0 and then
> play a song and then press again volume down key to reach 0 so you will get
> a silent phone.
> This is also related to DTMF tone silence because it now is content channel.

I don't quite understand this point. When going into silent mode, the plan is to  also automatically drop the content volume to 0.

Comment 21

[Larissa Co [:lco]]

(In reply to Joe Cheng from comment #17)
> what's the user impact if no changes are taken at this taken? do we have a
> very broken UX?

I believe all the volume rocker settings will have a lot of inconsistencies if no changes are made, but Alive has a better grasp of what the current behavior is.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Larissa Co from comment #18)
> Actually, I didn't
> think it would be necessary to store/restore the old volume (point #4), but
> either way is fine with me :) whichever is easier. I think it's acceptable
> to keep content volume at 0 if the user exits silent mode but has not
> modified the content volume.

If we don't save/restore the "content" volume it would mean that entering silent mode and then exiting silent would completely mute the "content" channel. That doesn't seem acceptable.

I think a founding principal if we are in a particular state, pressing the "volume down" button and then the "volume up" button should restore you to that state. Anything else would seem very surprising to the user.

I.e. the "volume up" button should generally undo what the "volume down" button did. And the other way around of course.

Comment 23

[Larissa Co [:lco]]

(In reply to Jonas Sicking (:sicking) from comment #22)
> (In reply to Larissa Co from comment #18)
> > Actually, I didn't
> > think it would be necessary to store/restore the old volume (point #4), but
> > either way is fine with me :) whichever is easier. I think it's acceptable
> > to keep content volume at 0 if the user exits silent mode but has not
> > modified the content volume.
> 
> If we don't save/restore the "content" volume it would mean that entering
> silent mode and then exiting silent would completely mute the "content"
> channel. That doesn't seem acceptable.
> 
> I think a founding principal if we are in a particular state, pressing the
> "volume down" button and then the "volume up" button should restore you to
> that state. Anything else would seem very surprising to the user.
> 
> I.e. the "volume up" button should generally undo what the "volume down"
> button did. And the other way around of course.

ok. I'm not going to argue much on this one. I see your point :)

Comment 24

[(inactive after 6/18) Alive Kuo [:alive]]

Redirecting needinfo to lco.
I believe I had stated clearly. Maybe Larrisa has more clear description. Larrisa, please see comment#17.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Joe Cheng from comment #17)
> what's the user impact if no changes are taken at this taken? do we have a
> very broken UX?

From my point of view:
Mute all possible channels could not be easily reached by volume rocker is not expected. See DTMF volume bug 784184. I think people would say he wants to mute the tone quickly instead of going to settings app to find a checkbox to close.

Comment 26

[Larissa Co [:lco]]

(In reply to Alive Kuo [:alive] from comment #24)
> Redirecting needinfo to lco.
> I believe I had stated clearly. Maybe Larrisa has more clear description.
> Larrisa, please see comment#17.

I also replied to this already, but to reiterate:
1. the behavior of the hardware rocker would be confusing -- the user would think he's silenced his phone but wonder why his content still has sound.
2. there would be no way to mute content volume if the ringer volume is muted.

Comment 27

[(inactive after 6/18) Alive Kuo [:alive]]

Renominate per #26

Comment 28

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB-, tracking-b2g18+. 
Without the fix, it's only that muting the ringer channel does not mute the content channel. as a user, can live with it for v1. just need to mute the content channel immediately when content is played in silent mode. (in android muting the phone does not seem to mute content either).

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is making audio for apps very confusing for users. Something we really should fix for leo.

Comment 30

[Joe Cheng [:jcheng] (please needinfo)]

triage: tracking-b2g18+, would not block release with this but would take a patch and consider for uplift approval

Comment 31

[(inactive after 6/18) Alive Kuo [:alive]]

I am hearing from many people complain about this and since bug 846092 is blocked by a platform issue(mozWriteAudio), this may be a workaround to help the user to mute the key tone.

Comment 32

[Askeing Yen[:askeing][:fyen]]

How about add option "Enable Silent Mode" when long-press power button to mute all channels?
And "Disable Silent Mode" will recover the last settings.

Comment 33

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Askeing Yen[:askeing] from comment #32)
> How about add option "Enable Silent Mode" when long-press power button to
> mute all channels?
> And "Disable Silent Mode" will recover the last settings.

The function in device menu is "silent incoming call" already. 
I agree this may be another trigger to silent mode if we do so, but in some case you won't have time to invoke device menu. For instance, the phone is in your pocket and making sounds.

Comment 34

[(inactive after 6/18) Alive Kuo [:alive]]

WIP:
https://github.com/alivedise/gaia/commit/45a3076aca2ea66ec5520aa465507d4155e99640

It's nearly done but I am not sure if I need to restore content volume when
1. In silent mode already
2. The device is rebooted

ni? from cyee
My opinion is get rid of silent mode when rebooting.

Comment 35

[Casey Yee]

I had a chat with Alive about this on site here in Madrid.   If the silent mode was enabled before restarting, the silent mode should be retained until the user turns it off.

We have adequate UI to show the user that the phone is in silent mode in the status bar and lock-screen.

Comment 36

[(inactive after 6/18) Alive Kuo [:alive]]

Nominate for leo? because this blocks 846092.

Comment 37

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

This seems to also block bug 827337, i.e. unlock screen sound is not affected by volume/mute state.

Comment 39

[Alex Keybl [:akeybl]]

Is this the lowest risk fix out of the bunch suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=846092#c6?

Comment 40

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alex Keybl [:akeybl] from comment #39)
> Is this the lowest risk fix out of the bunch suggested in
> https://bugzilla.mozilla.org/show_bug.cgi?id=846092#c6?

I believe so(and IMO there may be no other way). 
Note: This just fixes part of the problem. Silent the DTMF tone may work with this but adjust the volume of DTMF tone still needs other work.

Comment 41

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Casey Yee [:cyee] from comment #35)
> I had a chat with Alive about this on site here in Madrid.   If the silent
> mode was enabled before restarting, the silent mode should be retained until
> the user turns it off.
> 
> We have adequate UI to show the user that the phone is in silent mode in the
> status bar and lock-screen.

Casey, I am going to separate the idea of modifying device menu to another bug because the patch is already complex enough in this bug. Although we need to discuss if we need a button/checkbox in quick settings or settings app to enable silent mode.

Comment 42

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/9371

Silent mode v1:
* Enter silent mode when using volume rocker reach 0 in notification channel
* Leave silent mode when using volume to become more than 0 in notification channel
* Use asyncStorage to record previous content volume

Comment 43

[Juan Perez-Bedmar [:juanpbf]]

Hi, 
sorry for entering this discussion at this time, but I wanted to share my view, as this issue has been mentioned during certification process.

According to Telefonica offical Requirements, "Silent mode" must turn off contents sounds:
----------------------------------------------------------------------------------
		If a "Silent" profile is selected in the device, the device shall mute the audio during reproduction.
----------------------------------------------------------------------------------

Regarding other sounds such as keypress or camera shutter, I haven't found a specific requirement but, IMHO, they should be definitely off in "Silent" mode.

David, Beatriz, although this is certainly not a blocking issue, shall we make a dependency with the certif. meta?

Comment 44

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 741216 [details]
https://github.com/mozilla-b2g/gaia/pull/9371

Looks good for leo+.

Comment 45

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 741216 [details]
https://github.com/mozilla-b2g/gaia/pull/9371

There are some lint error though.

Comment 46

[(inactive after 6/18) Alive Kuo [:alive]]

master https://github.com/mozilla-b2g/gaia/commit/2a6b7ec077c838db50ea28e016d0db4ae3434582
fix some lint fail in sound manager.

Comment 47

[David Palomino [:dpalomino]]

(In reply to Juan Perez-Bedmar [:juanpbf] from comment #43)
> 
> David, Beatriz, although this is certainly not a blocking issue, shall we
> make a dependency with the certif. meta?

Hi Juan, 

Yes, there is no problem, it can block meta cert bug, but not prio P1 or tef?. Meta bug just means what it was reported during certification. 

Thanks!
David

Comment 48

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 2a6b7ec077c838db50ea28e016d0db4ae3434582 to:
v1-train: f8b0a9f27a701035964d0a09c250fcdadb303a99

Comment 49

[Andrew Overholt [:overholt]]

Just so we're 100% clear, loud (IMO) DTMF tones and camera "shutter" sound even when volume is set at 0 are okay from TEF's perspective for v1.0.1?

Comment 51

[(inactive after 6/18) Alive Kuo [:alive]]

I'd like to ask tef? because this blocks bug 867912 IMO....

Comment 52

[(inactive after 6/18) Alive Kuo [:alive]]

I'd like to ask tef? because this blocks bug 867912 IMO....

Comment 53

[(inactive after 6/18) Alive Kuo [:alive]]

Sigh, didn't mean to unblock..

Comment 54

[Andrew Overholt [:overholt]]

(In reply to Alive Kuo [:alive] from comment #52)
> I'd like to ask tef? because this blocks bug 867912 IMO....

Setting tef? (from leo+).

Comment 55

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'd be worried about uplifting this new feature into the v1.0 release. Though I definitely think that there's a risk that we'll get dinged for not having such a basic feature.

Comment 56

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jonas Sicking (:sicking) from comment #55)
> I'd be worried about uplifting this new feature into the v1.0 release.
> Though I definitely think that there's a risk that we'll get dinged for not
> having such a basic feature.

I agree though we've brought the brand new audio CE certification feature because of OEM partner request..
If partner doesn't think this and bug 867912 blocks their release, it's fine not to pick a big patch.

Comment 57

[Daniel Coloma:dcoloma]

(In reply to Andrew Overholt [:overholt] from comment #49)
> Just so we're 100% clear, loud (IMO) DTMF tones and camera "shutter" sound
> even when volume is set at 0 are okay from TEF's perspective for v1.0.1?

Ideally they should be fixed, but don't believe they should be blockers as they have independent controls to be activated/deactivated.

(In reply to Alive Kuo [:alive] from comment #51)
> I'd like to ask tef? because this blocks bug 867912 IMO....

However, bug 867912 is a blocker for me: if the device is put in silent, it should be maintained after rebooting it. If this bug is the only option for fixing bug 867912 we should block on this.

Comment 58

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Daniel Coloma:dcoloma from comment #57)
> However, bug 867912 is a blocker for me: if the device is put in silent, it
> should be maintained after rebooting it. If this bug is the only option for
> fixing bug 867912 we should block on this.

If you really care about the code size here and there, I think I have a quicker and simpler way to resolve what you say. Only the asynchronous state.
CONS:
1) Without the feature of silent mode.
2) Need some additional work.
3) this will increase the difficulty to maintain the v1.0.1 code.

Comment 59

[Daniel Coloma:dcoloma]

Based on previous comments I think the best option is uplifting this to v1.0.1

Comment 60

[Kai-Chih Hu [:khu]]

Talked with Alive and he will uplift it to v1.0.1.

Comment 61

[(inactive after 6/18) Alive Kuo [:alive]]

v1.0.1
https://github.com/mozilla-b2g/gaia/commit/77e1a102fa9c49f0fb78e9bb88e8f2767d784631

Comment 62

[sarsenyev]

As per requirement the silence mode is working as expected on:
1)Ringing
2)SMS notifications
3)DTMF sound
4) After reboot the silence mode is still active
5)Muted "Camera shutter sound" only works on V1.1 build

The camera shutter sound still can be heard on the latest V1.0.1 build even when the volume is muted

Environmental  Variables:
Unagi Build ID: 20130604070205
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/997cdbf5d012
Gaia: 5534304aee934055f08f21ce93261ba2a596516a

Inari Build ID: 20130604070207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/42555e1e72fa
Gaia: bf10abc41a01516995a99f3c6727a612bbdfe755