832170 - [Dialer] The Key Tone will be Routed to both of Headset & Speaker.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[Marco Chen [:mchen]]

According to bug 784184, it set audio channel of key tone to ringer. And the audio policy manager will set audio routing path to both of speaker and headset for stream belonged to ringer type.

Is this acceptable by our Product/UX spec?

Comment 1

[Casey Yee]

If the headset is plugged in the dialer tones should end up routing to the headset only.  Generally speaking we want to make sure that while the headset is plugged in the handset remains silent.

Comment 2

[Marco Chen [:mchen]]

(In reply to Casey Yee [:cyee] from comment #1)
> If the headset is plugged in the dialer tones should end up routing to the
> headset only.  Generally speaking we want to make sure that while the
> headset is plugged in the handset remains silent.

Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=823045#c34
The conclusion there is to allow ring tone came from headset and speaker if headset is plugged in. Since dialer key tone is set to "mozAudioChannelType='ringer'", key tone will be routed to headset and speaker too.

Comment 3

[Marco Chen [:mchen]]

Hi Casey,

Please refer to comment 2 for the reason of why ringer type will be fired to both speaker and headset. 

A possible solution is that there is a audio type called DTMF in android audio backend. Maybe we can add this new type into mozAudioChannelType and link it's volume to ringer. How about it?

Comment 4

[Casey Yee]

(In reply to Marco Chen [:mchen] from comment #3)
> A possible solution is that there is a audio type called DTMF in android
> audio backend. Maybe we can add this new type into mozAudioChannelType and
> link it's volume to ringer. How about it?

Sounds good to me :)

Comment 5

[Marco Chen [:mchen]]

History:

  Set dialer key tone to normal:
    The problem is that user can't adjust key tone volume because ringer is a default channel for adjusting by HW volume keys. And there is no slide bar in setting for normal/content channel.

  Set dialer key tone to ringer:
    Audio HAL module will automatically route ringer stream into both of speaker and headset. But that is not the expected behavior of dialer key tone.
  And ringer channel will be muted by Audio HAL module during in_call state.

So here will add a DTMF channel type for dialer key tone.

Comment 6

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Sounds good to me, too.

Comment 7

[Marco Chen [:mchen]]

Attachment: Part 1: Web IDL v1

Hi Jonas,

Please refer to comment 5 for why does we need to add this new channel type - DTMF. Thanks.

Comment 8

[Marco Chen [:mchen]]

Attachment: Part 2 - Permission of audio-channel-dtmf

Comment 9

[Marco Chen [:mchen]]

Attachment: Part 3: Other v1

Wait for superreview passed then start to review other parts.

Comment 10

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

Not blocking. The fact that it's hard to adjust the volume of the normal channel is well known (bug 825970).

Please renominate if I'm missing something.

Comment 11

[Marco Chen [:mchen]]

Hi Jonas,

According to bug 825970, the key tone in dialer is set to ringer channel now, so the key issue here is not for bug 825970.

The problem is that 
  1. any audio associated to ringer channel type will be routed to headset and speaker patches by audio HAL. And that is not acceptable by aspect of UX. 
  2. any audio associated to ringer channel will be muted by audio HAL during in_call state.

Due to the reasons above we can't set key tone to ringer state. If we set it back to normal channel then it will be hard to adjust volume. So if we doesn't want to add DTMF channel type here, then we need set key tone in dialer back to normal channel.

In perspective of UX (comment 4), he can accept the new DTMF channel.

Thanks.

Comment 12

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

I don't think moving the audio to a new DTMF channel is the right solution. The real problem here is that it's hard to adjust the volume of the "normal" channel.

Moving the audio from the "normal" volume to the "ringer" volume just skirts the issue. And it skirts the issue in a way that can't be used by 3rd party apps.

It also makes the system more complex because it means that if the user reduces the "normal" volume, suddenly that affects most application audio except DTMF tones, which seems confusing.

Comment 13

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

So what I think we should do is to move the DTMF tones back to the "normal" channel and then try to solve bug 825970. Or make it easier to adjust the "normal" volume some other way.

Comment 14

[Marco Chen [:mchen]]

Go back to bug itself then decide the tef? first because the key tone routing to both of headset & speaker is very weird and annoying.

Comment 15

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

If we change to use the "normal" channel that won't happen, right?

Comment 16

[Marco Chen [:mchen]]

(In reply to Jonas Sicking (:sicking) from comment #15)
> If we change to use the "normal" channel that won't happen, right?

Right. normal channel doesn't route to both of speaker and headset.
                      doesn't be muted by Audio HAL during in_call state.

But we need to reopen
  Bug 784184 - [Dialer] DTMF tone volume is not regulated by the volume button

Comment 17

[Alex Keybl [:akeybl]]

For v1.0.0, let's back out bug 784184 and set the DTMF tone volume to 50% (the lowest risk solution we can think of) to mitigate a majority of the impact originally found in bug 784184.

Comment 18

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

Comment on attachment 705765 [details] [diff] [review]
Part 1: Web IDL v1

Review of attachment 705765 [details] [diff] [review]:
-----------------------------------------------------------------

Minusing this so that we can go with the different solution.

Comment 19

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

reassign to alive as he's the assignee of bug 784184.
if we were to implement as comment 17, then users will have to bear with DTMF tones disturbing people when the phone is in silent mode.

adding more UX/Product to be aware of this.

Comment 20

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

comment 17 is impossible for the 50% volume. Because if we change back to normal channel, it just follows the settings of content channel.
Seems we need to implement some part of silent mode.

Comment 21

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

(In reply to Alive Kuo [:alive] from comment #20)
> comment 17 is impossible for the 50% volume. Because if we change back to
> normal channel, it just follows the settings of content channel.
> Seems we need to implement some part of silent mode.

Uh, O.K. So what we could do is hardcode the volume factor in gaia.
Don't need silent mode.

Comment 22

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

Yeah, that was the idea. I thought that it would work to simply stick a <audio volume="0.5" src=...> attribute on there, but apparently HTML5 *still* doesn't support this :(

So you have to set the element.volume property on the element using javascript. That way the volume will be scaled down by the Gecko code before feeding the audio into the audio backend.

Comment 23

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

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

Patch v1

Comment 24

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

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

r+ if this is the acceptable fix discussed.

Comment 25

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

Master
https://github.com/mozilla-b2g/gaia/commit/e67bcac1ee122c178e4162060afc83c2401ec1cb

v1.0.0:
https://github.com/mozilla-b2g/gaia/commit/7c4e332cf5d1ba967cd9561cc2df5333e80cf1de

v1-train:
https://github.com/mozilla-b2g/gaia/commit/876a6ddd65ec7a21bc29bbe6b2409de286eba9d6

Comment 26

[Cody Roesch [:croesch]]

Unagi Build: 20130322070202
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/5aacf880400b
Gaia   5a31a56b96a8fc559232d35dabf20411b9c2ca1d
Kernel: Dec 5th

In the above build, the key tone will always be routed properly whether the headphones are plugged in or not. If the headphones are plugged in, the key tone will always go through the headphones. If not then it goes through the speaker. Even if you are actively typing numbers into he keypad and plug in or pull the headphones, the behavior switches and works correctly.

Marked as Verified Fixed

Comment 27

[Cody Roesch [:croesch]]

Issue still repro's in V1 Train.

Comment 28

[Cody Roesch [:croesch]]

Build ID: 20130329070203 
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/5cc5df16447a
Gaia: 26b463f14caa11e0fc64fda09a17054da4bea68b

Now verified as fixed in V1 train.