Closed Bug 832170 Opened 10 years ago Closed 10 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:tef+, b2g18 verified, b2g18-v1.0.0 fixed, b2g18-v1.0.1 verified)

VERIFIED FIXED
blocking-b2g tef+
Tracking Status
b2g18 --- verified
b2g18-v1.0.0 --- fixed
b2g18-v1.0.1 --- verified

People

(Reporter: mchen, Assigned: alive)

References

Details

Attachments

(4 files)

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?
Flags: needinfo?(kyee)
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.
Flags: needinfo?(kyee)
(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.
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?
Flags: needinfo?(kyee)
(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 :)
Flags: needinfo?(kyee)
Depends on: 833268
Blocks: 833268
No longer depends on: 833268
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.
Summary: [Dialer] Key Tone will be Fired from Both of Speaker and Headset. → [Audio] Add a new audio channel type called DTMF for key tone of dialer App.
Sounds good to me, too.
Blocks: 796514
Hi Jonas,

Please refer to comment 5 for why does we need to add this new channel type - DTMF. Thanks.
Assignee: nobody → mchen
Attachment #705765 - Flags: review?(jonas)
Attachment #705765 - Attachment description: Part 1: IDL v1 → Part 1: Web IDL v1
Attachment #705765 - Flags: review?(jonas) → superreview?(jonas)
blocking-b2g: --- → tef?
Attached patch Part 3: Other v1Splinter Review
Wait for superreview passed then start to review other parts.
Attachment #705781 - Attachment description: Patch v2 - Permission of audio-channel-dtmf → Part 2 - Permission of audio-channel-dtmf
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.
blocking-b2g: tef? → -
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.
Flags: needinfo?(jonas)
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.
Flags: needinfo?(jonas)
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.
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.
Assignee: mchen → nobody
blocking-b2g: - → tef?
Summary: [Audio] Add a new audio channel type called DTMF for key tone of dialer App. → [Dialer] The Key Tone will be Routed to both of Headset & Speaker.
If we change to use the "normal" channel that won't happen, right?
(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
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.
blocking-b2g: tef? → tef+
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.
Attachment #705765 - Flags: superreview?(jonas) → superreview-
Assignee: nobody → mchen
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.
Assignee: mchen → 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.
(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.
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.
Patch v1
Attachment #708026 - Flags: review?(timdream)
Comment on attachment 708026 [details]
https://github.com/mozilla-b2g/gaia/pull/7860

r+ if this is the acceptable fix discussed.
Attachment #708026 - Flags: review?(timdream) → review+
QA Contact: cbarker
Flags: in-moztrap-
QA Contact: cbarker
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
Status: RESOLVED → VERIFIED
Issue still repro's in V1 Train.
Status: VERIFIED → RESOLVED
Closed: 10 years ago10 years ago
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.