Closed Bug 810780 Opened 12 years ago Closed 12 years ago

[Sound Manager] Hardware Volume Keys should react to phone's current state

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
VERIFIED FIXED
Milestone:
B2G C2 (20nov-10dec)
Project Flags:
blocking-basecamp +

People

(Reporter: alive, Assigned: alive)

References

Details

Attachments

(1 file)

https://github.com/mozilla-b2g/gaia/pull/6911
(deleted), text/html
timdream
: review+
Details 
This is follow-up of 796658 795237.

After we separate the volume setting per stream/channel type,
we need to adjust the behavior of hardware volume keys.

For example,
Use case#1:
Set audio.volume.voice_call when the user presses volume rockers on a call.
Use case#1b:
Reject the call when the user presses volume rockers on ringing.

Use case#2:
Set audio.volume.system when the user presses volume rockers on listening music.

Need UX final input, need gecko support; this bug is for gaia side implementation.
Assignee: nobody → alive
blocking-basecamp: --- → ?
Summary: [Sound Manager] Hardware Volume Keys should control the setting per current situation → [Sound Manager] Hardware Volume Keys should react to phone's current state
Alive could you clarify what is the current behavior ?

Josh could you clarify what is the expected behavior ?
Flags: needinfo?(jcarpenter)
(In reply to dscravaglieri from comment #1)
> Alive could you clarify what is the current behavior ?
> 

The current behavior is to always change the master volume.

> Josh could you clarify what is the expected behavior ?

Alive and others have a proposal at https://etherpad.mozilla.org/sound-stream-types and how it should be handle.

Alive, I feel like it miss some pieces from the platform here. Like an event coming from the chrome side telling the system app which channels is currently playing. CC'ing Jonas.
Flags: needinfo?(jcarpenter) → needinfo?(jonas)
(In reply to Vivien Nicolas (:vingtetun) from comment #2)
> Alive, I feel like it miss some pieces from the platform here. Like an event
> coming from the chrome side telling the system app which channels is
> currently playing. CC'ing Jonas.

You are right, we need some *more* mozChromeEvent support here, see https://wiki.mozilla.org/WebAPI/AudioChannels#System_and_Browser_API_changes

I should file a platform bug for this if there's an existing one now.
I see Jonas has already filed a platform bug for this :)
https://bugzilla.mozilla.org/show_bug.cgi?id=811222
Depends on: 811222
Blocks: 811224
Josh what are the requirement for that
blocking-basecamp: ? → +
Flags: needinfo?(jonas) → needinfo?(jcarpenter)
Priority: -- → P1
Changed needinfo to Casey, who is UX contact for audio issues, and was in meetings with Alive, Jonas etc during SF work week.
Flags: needinfo?(jcarpenter) → needinfo?(kyee)
Hi there, 
Volume rocker behavior:

- When there is no content (music, video, fm radio, web page audio) being played the volume rocker keys should be default adjust the ringer volume.
- When there is content is being played the volume rocker should adjust the content audio stream.
- When there is a active call, the volume rocker should adjust the call volume.

Incoming calls:
- When there is a incoming call (ringing), pressing the volume rocker should reject the call.

Alarms:
- When the alarm rings, pressing the volume rocker should dismiss the alarm.
Flags: needinfo?(kyee)
(In reply to Casey Yee [:cyee] from comment #7)
> Incoming calls:
> - When there is a incoming call (ringing), pressing the volume rocker should
> reject the call.
> 
> Alarms:
> - When the alarm rings, pressing the volume rocker should dismiss the alarm.

Is closing the alarm attention screen and call screen from system app an accepted implementation, vivien?
Or we need more mozContentEvent, which is sent to gecko, for it to close what should be closed.
Just as a note:  I'm less concerned about the incoming call and alarm behavior than I am about implementing the proper volume behavior while there is media content playing vs not playing.   

It may be worth splitting this into two separate bugs so we can prioritize the work properly?
(In reply to Casey Yee [:cyee] from comment #7)
> Incoming calls:
> - When there is a incoming call (ringing), pressing the volume rocker should
> reject the call.
> 
> Alarms:
> - When the alarm rings, pressing the volume rocker should dismiss the alarm.

Are these two v1 requirements? I think that the system app can get to the call and reject it, so this might be easy to implement.

However the system app has no idea what the alarm app is doing. And the alarm app has no way of getting notified when the volume rocker is used. So fixing this would be quite hard. At the very least I think we should have a separate bug on this and ask the PMs if that really is a blocker.
(In reply to Casey Yee [:cyee] from comment #7)
> Hi there, 
> Volume rocker behavior:
> 
> - When there is no content (music, video, fm radio, web page audio) being
> played the volume rocker keys should be default adjust the ringer volume.
> - When there is content is being played the volume rocker should adjust the
> content audio stream.
> - When there is a active call, the volume rocker should adjust the call
> volume.
> 
> Incoming calls:
> - When there is a incoming call (ringing), pressing the volume rocker should
> reject the call.
I think it's better to mute the ringtone instead of reject the incoming the phone call.
Users may press the volume key when  they get the phone from bags/pockets.
> 
> Alarms:
> - When the alarm rings, pressing the volume rocker should dismiss the alarm.
(In reply to Randy Lin [:rlin] from comment #12)

> I think it's better to mute the ringtone instead of reject the incoming the
> phone call.
> Users may press the volume key when  they get the phone from bags/pockets.


Hi Randy,
I agreed with you. I just tried my own phone and saw the behavior like you said.
(In reply to vliu from comment #13)
> (In reply to Randy Lin [:rlin] from comment #12)
> 
> > I think it's better to mute the ringtone instead of reject the incoming the
> > phone call.
> > Users may press the volume key when  they get the phone from bags/pockets.
> 
> 
> Hi Randy,
> I agreed with you. I just tried my own phone and saw the behavior like you
> said.

As a user, I also think that *mute* makes senses for me, rather than rejecting.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #14)
> As a user, I also think that *mute* makes senses for me, rather than rejecting.

Yep, agreed. We can revisit it v2.
Are tracking in bug 812690:  Mute call when volume buttons are pressed during incoming call
Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.
Target Milestone: --- → B2G C2 (20nov-10dec)
As the platform bug 811222 is reviewing, I am working on this.
There are still some detail we don't come up with a conclusion now, about 1)rejecting call or 2)dismiss alarm.
I will do what :cyee said in #7 except for those we cannot do and are tracking in another bugs now.

(In reply to Casey Yee [:cyee] from comment #7)
> Hi there, 
> Volume rocker behavior:
> 
> - When there is no content (music, video, fm radio, web page audio) being
> played the volume rocker keys should be default adjust the ringer volume.
> - When there is content is being played the volume rocker should adjust the
> content audio stream.
> - When there is a active call, the volume rocker should adjust the call
> volume.
Hi,
according comments above and bug 814326 and lco/casey is having a new spec about sound settings,
the behavior in comment 7 should be adjusted.
Proposal:
* Adjust ringer/notification volume settings(they are listening to the same setting, but still different channel) when no content is playing.
* Adjust content/normal volume settings(they are listening to the same setting, but still different channel, in order to meet audio competing policy) when content/normal is playing.
* Adjust telephony volume settings when on a call.
if 812692 and 812690 doesn't meet the C2, the alternative behavior is:
* When call incoming: Adjust ringer/notification volume settings still. I think everyone at least would expect the volume rocker is still functional when ringing.
* When alarm goes off: Adjust alarm volume settings still. I think everyone at least would expect the volume rocker is still functional when alarming is sounding. According to https://bugzilla.mozilla.org/show_bug.cgi?id=796259#c23 alarm is now having a close button so we don't strongly need the volume rocker to close it.

c.c. lco
My understanding was that when no audio was the volume of *all* channels should be modified. Essentially the settings app would be used to adjust the relative volume between the channels, but when you used the volume keys all channels were increased/decreased by the same amount.

I'd really like to have a detailed spec for how this should behave.
comment 21 is for lco
Flags: needinfo?(lco)
(In reply to Jonas Sicking (:sicking) from comment #22)
> My understanding was that when no audio was the volume of *all* channels
> should be modified. Essentially the settings app would be used to adjust the
> relative volume between the channels, but when you used the volume keys all
> channels were increased/decreased by the same amount.

I think that will cause problem if there are a, b channels:
* Set slider a to 0 and slider b to 10 in settings.
* Press volume key up or down => What's the result? What channel should be displayed on volume overlay? 0 or 10?

This doesn't make sense IMO. Android doesn't do well in this part, either.
It's still implementable. You'd have to remember the relative difference between the volumes in separate settings. And so when if one setting is set to 0 and another to 10 and the volume is increased, you'd set one volume to 1 and the other to 10. When it's decreased again it's set to 0 and 10.

But yes, it gets complicated. That's why I wanted things clarified by UX.
Bug 812690 and bug 812692 has both been marked blocking-, so this System app bug will not handle incoming calls and alarms as special cases.

We will do this for v1:

(In reply to Casey Yee [:cyee] from comment #7)
> Hi there, 
> Volume rocker behavior:
> 
> - When there is no content (music, video, fm radio, web page audio) being
> played the volume rocker keys should be default adjust the ringer volume.
> - When there is content is being played the volume rocker should adjust the
> content audio stream.
> - When there is a active call, the volume rocker should adjust the call
> volume.

But not these:

> Incoming calls:
> - When there is a incoming call (ringing), pressing the volume rocker should
> reject the call.
> 
> Alarms:
> - When the alarm rings, pressing the volume rocker should dismiss the alarm.

It will be great if lco can confirm these v1 behavior, but we won't block on it.

Thanks for clarification, Alive.
Blocks: 815705
Depends on: 815322, 815445
Depends on: 818824
Hi, 

Sorry, somehow I missed this thread in my inbox :(

I think everyone on this thread has seen this, but just in case, here is my current spec (v1 DRAFT): http://people.mozilla.com/~lco/FFOS/Sound/

On pg. 7, you'll find a table for the hardware rocker behavior. Here are some reactions to comments on this thread and in the related mailing list email about feasibility or design. Please let me know if I missed any of your questions!

1. Behavior on incoming calls / alarms
* I am ok with just adjusting volume for now if there is no easy way to ignore calls or stop the alarm. (Note that the desired behavior is to ignore calls, not reject them. People are really weird about rejecting certain calls outright and want to be passive-aggressive be ignoring them instead. Oh, human nature :) )

2. Silent mode complexity
* I know, I know. The Silent Mode behavior was a tough one for me to decide on too. My rationale for 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.
* 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?

3. How does the user know which channel he is adjusting when he presses the volume key? (question from Alive on email)
* If we do it right, we are matching the hardware rocker's behavior with the user's expectation, and it will just feel natural to him. Sounds like a fluffy answer, but this is how our brains work. If my content volume is too loud and I hit the volume buttons, I expect them to control the content because that's what's primarily on my mind; I'm not even thinking about the ringer volume. If I'm going to a movie theater and I want to silence my phone, I'm not even thinking about how the action is going to affect my music volume later down the line.
* In the future, I wouldn't mind having an additional icon to support the different states, but I don't think this is essential, honestly.
Flags: needinfo?(lco)
Blocks: 819184
Thanks for reply! We are near the target.

(In reply to Larissa Co from comment #28)
> 2. Silent mode complexity
> * I know, I know. The Silent Mode behavior was a tough one for me to decide
> on too. My rationale for 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.

This makes sense but the design is somehow different than this IMO. :)
My idea to 'mute' is: 
Just mute content and notification if one of them is down to zero by volume rocker.
Leave alarm and voice volume set to settings app and on call.

Others look good to me.
Flags: needinfo?(lco)
It seems we cannot reach a consensus on silent mode design. Let's put it to another bug and let this bug go on based on the spec and #28.
QA Contact: wachen
Depends on: 819858
Alive,

Let me know if I can help with this bug. I have not been following the recent audio threads, but I wrote apps/system/js/hardware_buttons.js
https://github.com/mozilla-b2g/gaia/pull/6911/files
Patch proposal:
1. Remove unnecessary mode check
2. Remove vibration icon under non-notification channel
3. Remove content volume setting in Settings app

This patch doesn't:
1. Restore vibration setting while the user from mute mode to unmute mode.
2. Combine mute settings of notification and content channel.
Attachment #690301 - Flags: review?(timdream+bugs)
https://github.com/mozilla-b2g/gaia/commit/59cfb8ea71b995efb1068a2a30f8cff0fb8c35c4
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 815452
Fixed in 20121212 build
Status: RESOLVED → VERIFIED
Flags: needinfo?(lco)
Blocks: 994991
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: