871467 - [AudioChannel] To generate alert tone during in_call state when alarm/notification is fired.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Marco Chen [:mchen]]

User scenario:
  What will be happened when alarm is fired during voice call.

  Currently: There is no sound/vibrator/screen during voice call.
             User will just see alarm after end of voice call.

Drawback:
  User will lose that alarm during voice call until end of call.

Plan:
  User will hear alert tone (ex: Do..Do..Do) when alarm is fired during voice call.

Extension:
  May apply to all scenario which used alarm or notification audio channel. (ex: SMS coming, MMS coming).
  
We will try to get feedback from UX's point of view first then try to decide how to implement it.

Comment 1

[Marco Chen [:mchen]]

Hi UX team,

Could you give some feedback about this thought on Description?

Thanks.

Comment 2

[Rob MacDonald [:robmac]]

Hi Marco - Thanks for flagging us. Generally the alarm takes precedence because (a) the user has requested it and (b)the consequences of having a requested alarm not go off can be severe in some instances.

As result, the alarm should follow the same behaviour during a phone call as it does when there is no phone call. It's disruptive, I know, but that is why it's called an "alarm". :)

So, to summarize, we agree with your plan to sound the alarm / vibrate and display the alarm dialog while in a call.

- Rob

Comment 3

[[e-mail], [e-mail]]

I figure out these behavior of synchronous alarm/phone call which are defined in previous issues as following:

Bug 809087 - [Clock] Turn off the active alarm (screen + sound) automatically when there is a incoming phone call

Bug 814632 - [Clock] Put a "silent" alarm screen underneath the oncall screen if the alarm goes off during a phone call 

Bug 804394 - [Clock] if more than one alarm is set and goes off and the screen lock is placed, only the top alarm is disabled.

If we want to implement the feature of generating alert tone, we should have a detail spec. and considerate existing behavior.

Comment 4

[Marco Chen [:mchen]]

Hi Ian,

Thanks for your follow up.
And I might split the tasks into UX, Gaia & Gecko side.

Stage 1:
  UX: Please provide the full wireframe on related use cases including what Ian posted on comment 3. 

Stage 2:
  Gaia: Modify the change corresponding to new wireframes.

Stage 3:
  Gecko: Add logic into AudioChannelService for pausing music from Alarm app and fire tone as telephony channel into the receiver or other output device.

Thanks for all your supporting here.

Comment 5

[Rob MacDonald [:robmac]]

I'll review this in detail and confirm the approach from the UX perspective on Friday.

Comment 6

[Rob MacDonald [:robmac]]

Hi everyone...

Although I haven't had a chance to put together a full spec for this, here's a proposed summary of behaviour based on this and other related bugs as well as reviews of other devices. 

SCENARIO 1 - Alarm goes off during a call

* The alarm should sound once through the active speaker (speakerphone or standard speaker). I suggest using the "Bell" tone that is currently used for notifications.
* If the alarm is set to vibrate, vibrate the phone once.
* Display the Active Alarm screen in the foreground and keep the display on for 15 minutes if the alarm is not dismissed. Dismissing the alarm restores the call screen.

I understand this is a change from what was suggested in other bugs, but it is imperative that the user be notified even while in a call. (Reviewing other devices, they typically sound the full alarm, which is even more disruptive.)

SCENARIO 2 - Alarm goes off while the phone is ringing

Wait until the call is answered, dismissed or the ringing stops. If the phone is answered, after five seconds use the recommendation from Scenario 1. If the call is dismissed or the ringing stops (voicemail, hangup, etc.), after five seconds follow the standard alarm behaviour.

SCENARIO 3 - Alarm is sounding and a call comes in

* Turn alarm sound off
* Turn alarm vibration off
* Turn alarm off
* Turn Active Alarm screen off
* Turn incoming call screen/sounds/vibration on
* Then follow the steps of scenario 2

SUMMARY
The key point with all of these scenarios is that we cannot fully suppress the alarm during a phone call. The user has requested the alarm and there could be a negative consequence if they are not notified.

Hopefully this all makes sense. And please flag me with any comments / questions / concerns. 

- Rob

Comment 7

[Marco Chen [:mchen]]

> SCENARIO 1 - Alarm goes off during a call

> * The alarm should sound once through the active speaker (speakerphone or standard speaker). > I suggest using the "Bell" tone that is currently used for notifications.

Hi Rob,

About changing the alarm tone during voice call, I think that would be better to cover by Gecko because
  1. Alarm app used alarm channel to play the tone but it will be blocked by AudioChannelService because a higher channel - telephony is ongoing there.
  2. Telephony channel should be used by a few apps like dialer and VOIP ones.

So my suggestion is that alarm app is no necessary to change the alarm tone according to phone state but just fire what user selected. Then Gecko side (or cooperate with system app) will monitor the alarm/notification channels then be a agent to fire tone on telephony channel during voice_call state.

Is this ok for you?

Comment 8

[Rob MacDonald [:robmac]]

Hi Marco...

This makes sense to me, but I'm not a system architect so I'm probably not qualified to answer this one. :)

From what you're saying, though, telephony will block the alarm unless Gecko handles it. I'd really like to have a beep or tone of some sort, though so hopefully this is feasible. In some hardware, the screen shuts off when it detects the phone is next to the user's ear, which means the screen-only alert could be easily missed in future devices. What's involved in getting this covered by Gecko?

Also, on a separate topic, I'm wondering about the idea of shutting off the alarm sound after 15 minutes if it's not dismissed. 15 minutes seems quite long and I was thinking more in the realm of 5 minutes. Is this difficult to change?

- Rob

Comment 9

[Marco Chen [:mchen]]

(In reply to Rob MacDonald [:robmac] from comment #8)
> Hi Marco...
> What's involved in getting this covered by Gecko?

Yes, we will handle it on the Gecko (and maybe co-work with system app).
Then from user's point of view, it will just hear the beep from earphone but the real music from alarm or notification.

About timeout of alarm, I think maybe Ian can answer it.
Ian, could you help this? Thanks.

Comment 10

[[e-mail], [e-mail]]

Hi Rob,

Thanks for your guidance such detail. Regarding comment 6, the three scenarios are more different from existing behavior. For each scenario, Clock app will need to get permission "telephony" for monitor call state(onincoming/connected). I'm not sure that we're able to get call state via audio channel. I think Macro could have some suggestion on it. So, it's a topic for discussion to let Clock app have permission "telephony". If we make sure to implement the new scenario, we should create new issue for tracking all of them.

Regarding the realm of alarm notification, we can modify it easily. But I feel notifying 5 minutes too short for me personally...

For the issue here, Clock app will check its visibility state for identifying background/forground mode. If it's in background mode, Clock app won't sound and vibrate(Bug 814632). Because a call screen is hover active alarm screen via attention screen module. If Gecko and UX are ready for generating alert tone in the scenario, Gaia will need to remove the mechanism.

Comment 11

[Marco Chen [:mchen]]

(In reply to Ian Liu [:ianliu] from comment #10)
Hi Ian,

May I know that whether clock app now will monitor the telephony state or not?

Comment 12

[[e-mail], [e-mail]]

(In reply to Marco Chen [:mchen] from comment #11)
> (In reply to Ian Liu [:ianliu] from comment #10)
> Hi Ian,
> 
> May I know that whether clock app now will monitor the telephony state or
> not?

No, Clock app does not monitor the telephony state now. It uses visibility status to identify the call screen is over or not. If we want to implement SCENARIO 1~3, I think it will need the telephony state.

Comment 13

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

Clock app shouldn't require telephony permission anyway.
Why do we need a clock to have telephony permission, do you want it to call out when you are overslept? =)

Comment 14

[Marco Chen [:mchen]]

Hi Ian and Alive,

Yes, why I ask this is for highlighting that we shouldn't let clock app monitor the telephony state. So when we feedback the UX scenarios from technical of view, we need to consider this criteria.

Comment 15

[Marco Chen [:mchen]]

Hi Rob,

Please refer to the comment 12 ~ 14, we think clock should not monitor the telephony state because clock app holds telephony permission is wired. So I would try to modify your proposal as

SCENARIO 1 - Alarm goes off during a call

* The alarm should sound a tone like "Be..Be.." through the active speaker (speakerphone or standard speaker). and the other part works as normal.
  (technical view: The alarm still sound what it do as normal case and Gecko will mute it and ask system app to fire "be..be.." sound.)

SCENARIO 2 - Alarm goes off while the phone is ringing

* Alarm will be on top of ringer screen and only ringer is fired then user needs to
  dismiss alarm first then pick up the call.

SCENARIO 3 - Alarm is sounding and a call comes in

* Alarm goes into snooze mode so after a period of time alarm will be fired again then maybe go into SCENARIO 1.
  (tech view: Alarm detects that it is on the background so put itself into snooze mode.)

May I know your opinions? Thanks.

Comment 16

[Stephany Wilkes]

This is a great deal of work, and needs to be scoped and added to the 1.4 backlog if it is going to be designed and completed. Flagging Chris Lee to find out who owns Audio so that we can make sure this is handled appropriately.

Comment 17

[Dominic Kuo [:dkuo]]

[UX_TRIAGED]

If we want to notify the user there is an alarm/notification during the call, the current audio competing policy is unable to achieve this, because the telephony has higher priority. Also, this is actually a feature that how we should notify the user during a call, we definitely need ux spec(maybe comment 6?) to implement it, and we need the new gaia audio management to support this. So it won't happen until we enable the gaia audio management.

Comment 18

[Jean Gong :jgong]

Adam, which PM would take care of this bug as is relates to gaia audio management policy?

Comment 19

[Adam Rogers (:arog)]

I believe it's Marvin (media platform).

Comment 20

[Marvin Khoo [:Marvin_Khoo]]

Hi Adam,
Media platform do not own any UI here, but handling audio confliction when multi channel occurred simultaneously. 

we shall look into Marco, Ian & Rob proposal, if you don't have any concern from UI behavior perspectives then UX can start working on WF.

Hi Marco,
Not sure except In_call vs Alarm (or Timer) stage, this should cover Notification(s) correct? 

moreover, does this fix cover Music playback or FM Radio vs Alarm / Timer / Notification(s), Video playback vs Alarm / Timer / Notification(s)?

Your proposal sounds good to me, however, when Alarm is triggered during In_call stage, i expect it shows up a dialog on top Phone UI with Snooze and Dismiss button, so it's easier for user to dismiss it.

For notification(s) with sound, i expect it just given Be sounds w/o any UI overlaid. 


BR,
Marvin

Comment 21

[Marco Chen [:mchen]]

(In reply to Marvin Khoo [:Marvin_Khoo] from comment #20)
> Not sure except In_call vs Alarm (or Timer) stage, this should cover
> Notification(s) correct? 

Yes, this proposal can cover notification too.
 
> moreover, does this fix cover Music playback or FM Radio vs Alarm / Timer /
> Notification(s), Video playback vs Alarm / Timer / Notification(s)?

I didn't know what we tried to fix on these scenario.

> Your proposal sounds good to me, however, when Alarm is triggered during
> In_call stage, i expect it shows up a dialog on top Phone UI with Snooze and
> Dismiss button, so it's easier for user to dismiss it.

Yes, this is one thing UX can cover it.

Comment 22

[Marco Chen [:mchen]]

(In reply to Dominic Kuo [:dkuo] from comment #17)
> [UX_TRIAGED]
> 
> we need the new gaia audio management to
> support this. So it won't happen until we enable the gaia audio management.

Hi Dominic,

My initial proposal is based on what we had now (implementing audio competing policy in the gecko) so it didn't reply on moving audio competing policy from gecko to gaia.

Please let me know if I missed something.

Comment 23

[Marvin Khoo [:Marvin_Khoo]]

(In reply to Marco Chen [:mchen] from comment #21)
>  
> > moreover, does this fix cover Music playback or FM Radio vs Alarm / Timer /
> > Notification(s), Video playback vs Alarm / Timer / Notification(s)?
> 
> I didn't know what we tried to fix on these scenario.
> 

sorry, let me put it more specific, just wondering if we already cover / save with following scenarios
for example: 
1. the audio behavior when Alarm triggered and Music / FM Radio is playback in foreground.
2. the audio behavior when Alarm triggered and Video is playback in foreground.

Comment 24

[Marco Chen [:mchen]]

(In reply to Marvin Khoo [:Marvin_Khoo] from comment #23)
> 1. the audio behavior when Alarm triggered and Music / FM Radio is playback
> in foreground.
> 2. the audio behavior when Alarm triggered and Video is playback in
> foreground.

Yes, current design in gecko already covered these cases. 
The result is that Music/FM will be paused during alarm triggered and be resumed after alarm sound is dismissed.
Video app has it's own design and it will pause video when detecting it is under background.

But maybe you can sync with Dominic about the reason of moving audio competing policy from gecko to gaia.

Comment 25

[BMO Automation]

Firefox OS is not being worked on