Closed Bug 832170 Opened 10 years ago Closed 10 years ago
[Dialer] The Key Tone will be Routed to both of Headset & Speaker
3.39 KB, patch
|Details | Diff | Splinter Review|
1.40 KB, patch
|Details | Diff | Splinter Review|
9.67 KB, patch
|Details | Diff | Splinter Review|
86 bytes, text/html
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?
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.
(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?
(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 :)
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.
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)
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.
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.
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-
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.
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+
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
Issue still repro's in V1 Train.
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.
You need to log in before you can comment on or make changes to this bug.