1073214 - [Dialer][Touch Tone] Touch tones sound harsh, possibly exceeding speaker range.

Status: RESOLVED WONTFIX

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

Description

[Martin Shuman [:Marty]]

Attachment: logcat-TouchTones.txt

Description:
The touch tones in the Dialer app sound very harsh and tinny. It's possible that the sound is exceeding the speaker range.

The touch tones also sound poor when listening to the device through headphones.

This issue is not present in Flame 2.1  builds, where Dialer touch tones sound clear.
   
Repro Steps:
1) Update a Flame device to BuildID: 20140925040206
2) Open the Dialer app.
3) Input a phone number with the keypad, listening to the touch tones.
  
Actual:
Touch tones sound poor, harsh.
  
Expected: 
Touch tones sound clear and appropriate.
  
Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20140925040206
Gaia: c5d2e2f4ebf5f370d6003517057dcd47493dec90
Gecko: 32acbe1d64dc
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
  
Notes:
  
Repro frequency: 5/5
See attached: logcat

--------------------------------------------------

This issue does NOT occur on Flame 2.1.
Touch tones sound clear and appropriate.

Environmental Variables:
Device: Flame 2.1
BuildID: 20140925000204
Gaia: 8061ab487d42cbc49b329fd68b9ca90e0fe477e6
Gecko: e970bc96f8b5
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 1

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Regression of a core feature of the phone, bad user experience.

Requesting a window.

Comment 2

[Joshua Mitchell (Inactive)]

Central Regression Window:
Last Working:
Device: Flame 2.2 Master
BuildID: 20140908062801
Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d
Gecko: f7a27a866c47
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken:
Device: Flame 2.2 Master
BuildID: 20140908155705
Gaia: 4acd3e69b263b54f4111e3586ff4ade84b49b4da
Gecko: 587f6c9b5a80
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
  
Gaia/Gecko Swap
Last Working Gaia First Broken Gecko: Issue does NOT reproduce
Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d
Gecko: 587f6c9b5a80
First Broken Gaia Last Working Gecko: Issue DOES reproduce
Gaia: 4acd3e69b263b54f4111e3586ff4ade84b49b4da
Gecko: f7a27a866c47

Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d...4acd3e69b263b54f4111e3586ff4ade84b49b4da

--------------------------------------------------------------------------------------------------------
B2G-Inbound Regression Window:

Last Working:
Device: Flame 2.2 Master
BuildID: 20140908133303
Gaia: 46e35fd6adc8f89d1b058ff84312cb38242c4658
Gecko: f8ff0b4698f3
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken:
Device: Flame 2.2 Master
BuildID: 20140908140304
Gaia: 96179a39249d0d7c7fd3485001c596c31b296cec
Gecko: b51330f06102
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Gaia/Gecko Swap
Last Working Gaia First Broken Gecko: Issue does NOT reproduce
Gaia: 46e35fd6adc8f89d1b058ff84312cb38242c4658
Gecko: b51330f06102
First Broken Gaia Last Working Gecko: Issue DOES reproduce
Gaia: 96179a39249d0d7c7fd3485001c596c31b296cec
Gecko: f8ff0b4698f3

Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/46e35fd6adc8f89d1b058ff84312cb38242c4658...96179a39249d0d7c7fd3485001c596c31b296cec



Broken by Bug 980854 - Can you take a look Gabriel?

Comment 3

[Gabriele Svelto [:gsvelto]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #2)
> Broken by Bug 980854 - Can you take a look Gabriel?

I assume you're referring to short tones. Those were using pre-recorded samples before bug 980854 landed and at maximum volume the Web Audio replaced does indeed sound harsher on the Flame. I'll have a look if tweaking the volume helps, I'll also test on other device to get a better perspective.

Comment 4

[Joshua Mitchell (Inactive)]

(In reply to Gabriele Svelto [:gsvelto] from comment #3)
> (In reply to Joshua Mitchell [:Joshua_M] from comment #2)
> > Broken by Bug 980854 - Can you take a look Gabriel?
> 
> I assume you're referring to short tones. Those were using pre-recorded
> samples before bug 980854 landed and at maximum volume the Web Audio
> replaced does indeed sound harsher on the Flame. I'll have a look if
> tweaking the volume helps, I'll also test on other device to get a better
> perspective.

I'm not sure about 'short' tones but this is one of those things that depends on who is doing the listening - The reporter described the tones as "harsh" - I thought they sounded "pitched" or "modulated" meaning that instead of a smooth even tone they would pitch up in the middle - possibly beyond the range of the phone speaker. Some testers couldn't hear the difference at all.

Comment 5

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Can Taipei QA reproduce? 
There may be some standard criteria for ear-friendly tones.

Comment 6

[Eric Chang [:ericcc] [:echang]]

I am not sure how bad that sounds, but it does sound differently from those in v2.1. Just not that clear when it ends, more like an sound of musical instrument in v2.2. 
And in v2.1, it sounds like there is a electric pulse after each tone.

Comment 7

[Gabriele Svelto [:gsvelto]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #4)
> I'm not sure about 'short' tones but this is one of those things that
> depends on who is doing the listening - The reporter described the tones as
> "harsh" - I thought they sounded "pitched" or "modulated" meaning that
> instead of a smooth even tone they would pitch up in the middle - possibly
> beyond the range of the phone speaker. Some testers couldn't hear the
> difference at all.

We've got two type of tones which are used depending on the context (in a call or not) and network (GSM vs CDMA). Long tones last as long as you keep a button pressed and those have always been generated via Web Audio. They used to be glitchy but we patched around until the proper Web Audio fix. Clearing short tones however didn't work using the workaround, so we had to use pre-recorded OPUS files of each tone. These tones are different than the ones we synthesize via Web Audio and they were less loud. If only short tones are affected then it's because of that, if long tones are also affected then we're looking at something else.

Comment 8

[KTucker [:KTucker][Inactive 3/4/2016]]

Joshua, can you verify the tones affected based on the information in Comment 7?

Comment 9

[Joshua Mitchell (Inactive)]

The testing was done around the dialer app - which is using only the short tones. 

I was not able to find anything that used long-tones but if I'm given specific steps I can test those too.

Comment 10

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: per comment 6, the sound is a bit different but not like a defect. 
I personally tried it with Eric. Same as comment 9, we were only able to get short tones.
Please renominate if there's clear STR which leads to significant user impact.

Comment 11

[Gabriele Svelto [:gsvelto]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #9)
> I was not able to find anything that used long-tones but if I'm given
> specific steps I can test those too.

Long tones are available only during a call but there's no need to test them as those didn't change; they've always been synthesized using Web Audio.

Comment 12

[BMO Automation]

Firefox OS is not being worked on