988760 - [Sora][IOT]Device doesn't play "busy line" tone when calling busy line but a very loud tone

Status: RESOLVED FIXED

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

Description

[sync-1]

Firefox OS v1.3
 Mozilla build ID: 20140312164001
 ______________________________________________________________________________
     A.- Overview Description (technical background, concise explanation of the bug):
     
     When calling to a busy line, device doesn't play "busy line" tone
     ________________________________________________________________________________
     B.- Steps to Reproduce (initial conditions, required resources, step by step instructions to reproduce):
     
     Call to a busy line --> check the screen and tones
     ________________________________________________________________________________
     C.- Actual Result (current bad behaviour that is reported as a bug):
     
     When calling to a busy line, DuT doesn't play "busy line" tone. Instead a big beep sound is heard.
     ________________________________________________________________________________
     D.- Expected Result (correct behaviour wished):
     
     It may show the "busy line" screen and play the corresponding tone 
 
 Check video and logs from this link:
 http://www.sendspace.com/file/hjo0qw

Comment 1

[isabelrios]

This is also happening on buri device with today's 1.3 build:
Gecko-4ec8d45
Gaia-8d15906

When calling to a busy number a tone is played very loud, like if the speaker is activated. And it is not the real busy tone.

This is a regression, see bug 910267, and also a blocker for certification. Nominating to 1.3

Comment 2

[Jason Smith [:jsmith]]

How is this bug any different than bug 984498?

Comment 3

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Jason Smith [:jsmith] from comment #2)
> How is this bug any different than bug 984498?

I think bug#984498 is about busy tone cannot play. This one is that the phone can play busy tone, but the tone is just not right.

Comment 4

[Mingming ZHAO]

The actual result is:

The busy tone is played after the call is disconnected and it is sound noise. Please refer to the video:
 http://www.sendspace.com/file/hjo0qw

Comment 5

[isabelrios]

(In reply to Jason Smith [:jsmith] from comment #2)
> How is this bug any different than bug 984498?

If you have the device next to your ear, as waiting to start the call, the sound of the bip is painful, it is very loud.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #3)
> (In reply to Jason Smith [:jsmith] from comment #2)
> > How is this bug any different than bug 984498?
> 
> I think bug#984498 is about busy tone cannot play. This one is that the
> phone can play busy tone, but the tone is just not right.

There's a problem here though. They are stating conflicting behaviors with the exact same STR on the same device. There really should be one bug here describing the scope of the problem with busy tones, not two.

Please add details to bug 984498 specifically here that cites what's happening with busy tones.

Comment 7

[Beatriz Rodríguez [:brg]]

Let me try to explain why we think this is a different bug, not a dup.
In bug 984498 --> we are reporting an issue of not playing the busy tone when the user has set the volumen to cero.
In this bug we are reporting that the busy tone(when it is played) is not a busy tone at all but just an annoying tone whicn can hurt your ears.
This bug is more critical than 984498. 
We are fine if the engineer fixes the issue in the same patch, but we want to clarify that the way to reproduce the issue is different. 
Reopening and nominating accordingly.

Comment 8

[Jason Smith [:jsmith]]

Okay - thanks for the clarification. I see the difference now.

Comment 9

[Star Cheng [:scheng]]

According to my investigation, I want to point out 2 problem:

1.web audio creates audio stream as fixed "AUDIO_CHANNEL_NORMAL" type instead of setting from gaia layer.
 -> The Web Audio API creates audio stream as "AUDIO_CHANNEL_NORMAL" type(http://dxr.mozilla.org/
    mozilla- central/source/content/media/MediaStreamGraph.cpp#814). It doesn't work even we set the 
    "telephony" audio channel type in Gaia layer.

2.there is no correct setting for waiting tone/busy tone.
  -> In dialer app, touch keypad will generate DTMF tone. It is set as "telephony" type. So is not be set muted 
     while in call. https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer
     /js/keypad.js#L234) 


Hi, Paul

I am not familiar with MediaStreamGraph. I need your help. Please provide more information about 1. and how to create audiostream base on the type of audiochannel.

Comment 10

[Star Cheng [:scheng]]

(In reply to Star Cheng [:scheng] from comment #9)
> According to my investigation, I want to point out 2 problem:
> 
> 1.web audio creates audio stream as fixed "AUDIO_CHANNEL_NORMAL" type
> instead of setting from gaia layer.
>  -> The Web Audio API creates audio stream as "AUDIO_CHANNEL_NORMAL"
> type(http://dxr.mozilla.org/
>     mozilla- central/source/content/media/MediaStreamGraph.cpp#814). It
> doesn't work even we set the 
>     "telephony" audio channel type in Gaia layer.
> 
> 2.there is no correct setting for waiting tone/busy tone.
>   -> In dialer app, touch keypad will generate DTMF tone. It is set as
> "telephony" type. So is not be set muted 
>      while in call.
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer
>      /js/keypad.js#L234) 
> 
> 
> Hi, Paul
> 
> I am not familiar with MediaStreamGraph. I need your help. Please provide
> more information about 1. and how to create audiostream base on the type of
> audiochannel.


I am sorry. This comment is not correct. Please ignore this.

Comment 11

[David Scravaglieri [:scravag]]

Etienne, sounds like a gecko issue, who could be the best to fix this ?

Comment 12

[Etienne Segonzac (:etienne)]

(In reply to David Scravaglieri [:scravag] from comment #11)
> Etienne, sounds like a gecko issue, who could be the best to fix this ?

Might be the side effect of a performance issue, Gabriele could probably figure this out for sure.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Etienne Segonzac (:etienne) from comment #12)
> (In reply to David Scravaglieri [:scravag] from comment #11)
> > Etienne, sounds like a gecko issue, who could be the best to fix this ?
> 
> Might be the side effect of a performance issue, Gabriele could probably
> figure this out for sure.

Could this be a web audio problem?

Comment 14

[Gabriele Svelto [:gsvelto]]

I've just reproduced this on my hamachi, I think that the sound being played is indeed the busy tone but it's horribly choppy; we already run into a similar issue due to Web Audio with keypad sounds so it might be a related issue. Also it's definitely not being played on the right channel. I'll do some further investigation before clearing the NI flag.

Comment 15

[Gabriele Svelto [:gsvelto]]

I've tried reverting the patches to the TonePlayer one by one and I found that this one introduced this particular issue:

https://github.com/mozilla-b2g/gaia/commit/c7495318fd68c6ee58a94c50c0c43d207db83dfc

Reverting it makes the busy tone clear again and also plays it on the right channel. Now the question is why :)

Comment 16

[Gabriele Svelto [:gsvelto]]

Actually on second thought I'm not sure that it's the audio channel that's wrong, it might just be that the volume is over-the-top.

Comment 17

[Gabriele Svelto [:gsvelto]]

After poking around with the code it seems to me that there's multiple issues contributing to this problem. First of all the duration of the oscillator nodes is completely wrong, the stopping time is set to 20+ seconds after the starting time which can't be right. Changing this line:

https://github.com/mozilla-b2g/gaia/blob/153a4cdbe3f8daa15695b0d7e6e58ee500c241f5/apps/communications/dialer/js/tone_player.js#L128

To:

oscNode.stop(when + duration);

Sets the correct duration making the busy tone audible though it works only half of the time, the remaining half nothing is played. Besides the volume is still through the roof.

Today it's getting late but tomorrow I'll try dumping out all the parameters involved in the various audio nodes and I'll try to figure out what needs fixing.

Comment 18

[Gabriele Svelto [:gsvelto]]

OK, here's what I found (and it looks like a Gecko issue alright):

The first time we access the audio context's |currentTime| attribute we get a wrong value. Once we touch any of the other Web Audio functions then querying |currentTime| again returns the correct value which - for the first invocation - is exactly twice the time we got from the first invocation. The net result is that the first time we play the tone sequence the duration of the various sounds is completely borked and all the tones overlap creating a ridiculously loud sounds.

I'll have a look into the implementation to figure out what's going wrong but in the meantime we might need a quick low-risk workaround here so I'll provide one. On a side note, even with this fixed the volume is wrong anyway so we'll have to fix that too.

Comment 19

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Workaround an issue with AudioContext.currentTime not being reported correctly the first time it's accessed

I'm trying to chase down the Gecko bug responsible for the issue we're hitting here but in the meantime to have a workable fix immediately I've prepared this Gaia patch that works around the issue.

Two small notes on the patch: this also helps with the glitchiness of the first played sound effectively clearing up the busy tone for its entirety which is a nice bonus. This is an idea I had come up with in bug 917193 and it turns out that it helps here too so let's do it. In fact in its slightly revised form it might be used to remove the ugly workaround in that bug (with a better workaround :-) ).

The second thing is that this does not solve the volume problem though the sound is not ear-piercing anymore at least. That particular issue is caused by the audio being played on the normal audio channel even if we set the telephony channel correctly. Bug 984498 is effectively the same issue as far as volume goes.

Comment 20

[Gabriele Svelto [:gsvelto]]

Attachment: [PULL REQUEST] Workaround for glitchy sound when playing the busytone

And here's the PR. Note that I've tested this on master using an hamachi device but also on v1.3t on a Tarako an d it fixes the problem there too.

Comment 21

[Etienne Segonzac (:etienne)]

Comment on attachment 8401875 [details] [diff] [review]
[PATCH] Workaround an issue with AudioContext.currentTime not being reported correctly the first time it's accessed

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

r=me with a comment referencing the opened gecko bug.

(I knew this bug couldn't resist you :))

Comment 22

[Gabriele Svelto [:gsvelto]]

(In reply to Etienne Segonzac (:etienne) from comment #21)
> r=me with a comment referencing the opened gecko bug.

I've identified where this is happening but not exactly why, I'll open a gecko bug ASAP or even provide a fix here if I'm able to cook up one. Still I'd be keen on keeping the dummy sound if only for the fact that it makes the following sound cleaner.

> (I knew this bug couldn't resist you :))

You flatter me :)

Comment 23

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH gecko] Account for extra time since blocking correctly

Here's a Gecko patch that seems to fix the problem for me though not being a Web Audio expert I'm unsure if it introduces other issues.

The issue here is that the first time AudioContext.currentTime is read we compute the time spent since we last blocked as there were no other nodes in the graph, this happens here:

http://hg.mozilla.org/mozilla-central/file/6c924a018540/content/media/webaudio/AudioDestinationNode.cpp#l552

This time is effectively the value of |currentTime| at this stage. When adding some actual nodes this time is added to the contents of |mExtraCurrentTime| here:

http://hg.mozilla.org/mozilla-central/file/6c924a018540/content/media/webaudio/AudioDestinationNode.cpp#l590

However since AudioDestinationNode::ExtraCurrentTime() returns the sum of |mExtraCurrentTime| and |mExtraCurrentTimeSinceLastStartedBlocking| - which have become equal at this stage - the value of currentTime effectively doubles on the spot and then starts growing.

To fix this I've just reset the contents of |mExtraCurrentTimeSinceLastStartedBlocking| to 0 after it was accumulated into |mExtraCurrentTime|. Since I'm not sure I understand this code correctly I don't know if this is actually the right solution or not. Karl can you help us out with this?

Comment 24

[Paul Adenot (:padenot)]

Gabriele, I think you just attached the wrong patch. roc or myself can surely help here, Karl probably can as well.

Comment 25

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH gecko] Account for extra time since blocking correctly

(In reply to Paul Adenot (:padenot) from comment #24)
> Gabriele, I think you just attached the wrong patch. roc or myself can
> surely help here, Karl probably can as well.

You're right, this is the right one.

Comment 26

[Karl Tomlinson (:karlt)]

(In reply to Gabriele Svelto [:gsvelto] from comment #22)
> Still
> I'd be keen on keeping the dummy sound if only for the fact that it makes
> the following sound cleaner.

Please reference bug 848954 about this.  When bug 848954 is fixed, the sound should be clean without this.

Comment 27

[Karl Tomlinson (:karlt)]

Comment on attachment 8401977 [details] [diff] [review]
[PATCH gecko] Account for extra time since blocking correctly

Thank you for the nice analysis!

>@@ -583,16 +583,17 @@
>     mExtraCurrentTimeSinceLastStartedBlocking = 0;

Would you mind removing this line, from the if (aIsOnlyNode) block, at the same time, please?
This seems to serve no useful purpose.  I think it was just put in the wrong place, as you have discovered.

r=me with that change.

Comment 28

[Gabriele Svelto [:gsvelto]]

(In reply to Karl Tomlinson (:karlt) from comment #26)
> Please reference bug 848954 about this.  When bug 848954 is fixed, the sound
> should be clean without this.

Yup, I'll modify bug 980854 which tracks removing the other workaround we had for this to also take into account this workaround.

(In reply to Karl Tomlinson (:karlt) from comment #27)
> Comment on attachment 8401977 [details] [diff] [review]
> [PATCH gecko] Account for extra time since blocking correctly
> 
> Thank you for the nice analysis!
> 
> >@@ -583,16 +583,17 @@
> >     mExtraCurrentTimeSinceLastStartedBlocking = 0;
> 
> Would you mind removing this line, from the if (aIsOnlyNode) block, at the
> same time, please?
> This seems to serve no useful purpose.  I think it was just put in the wrong
> place, as you have discovered.
> 
> r=me with that change.

Thanks for the review; I've removed that line and this is my try run:

https://tbpl.mozilla.org/?tree=Try&rev=46f5f0c5cf67

I ran the mochitests locally as they seem to be the only ones covering Web Audio functionality; everything went fine so I hope this sticks. I'll attach the updated patch shortly and see if it applies to the v1.3 branch too as we also need it there.

Comment 29

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH gecko v2] Account for extra time since blocking correctly r=karlt

Updated patch with comment 27 taken into account, carrying over the r+ flag.

Comment 30

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH gaia v2] Workaround for glitchy sound when playing the busytone r=etienne

Updated patch as per comment 21, carrying over the r+ flag.

Comment 31

[Gabriele Svelto [:gsvelto]]

Travis (*) was green so I've pushed the workaround for glitchy sound to gaia/master d3a918483a7342052ede64bcb5dc6c72f5356212

I'll now cherry pick / uplift it to 1.3 and then as soon as the try-run is green I'll also land the gecko fix and close the bug.

*) The run is here: https://travis-ci.org/mozilla-b2g/gaia/builds/22448879 The patch comment is wrong in this push but the patch is identical, I didn't bother with re-running the job with the changed comment.

Comment 32

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8402683 [details] [diff] [review]
[PATCH gaia v2] Workaround for glitchy sound when playing the busytone r=etienne

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 848954
[User impact] if declined: when the busy tone starts playing it sounds very scratchy
[Testing completed]: tested on hamachi / tarako devices
[Risk to taking this patch] (and alternatives if risky): the patch does not affect functionality, it just introduces a dummy sound to "warm up" the Web Audio code and reduce the scratching sound when we start playing the tone
[String changes made]: none

Comment 33

[Gabriele Svelto [:gsvelto]]

Travis was green though I had to re-trigger one test under Windows 7 to be sure it was really an intermittent and not something related to the change here.

For the sheriffs, what needs to land is attachment 8402682 [details] [diff] [review] on mozilla-central.

We'll deal with the uplifts only after this has stuck and I've got approval for the gaia part for v1.3/v1.4.

Comment 34

[bhavana bajaj [:bajaj]]

(In reply to Gabriele Svelto [:gsvelto] from comment #33)
> Travis was green though I had to re-trigger one test under Windows 7 to be
> sure it was really an intermittent and not something related to the change
> here.
> 
> For the sheriffs, what needs to land is attachment 8402682 [details] [diff] [review]
> [review] on mozilla-central.
> 
> We'll deal with the uplifts only after this has stuck and I've got approval
> for the gaia part for v1.3/v1.4.

Waiting for the needed patch to get RESOLVED and stick on central, before approving branch specific uplifts.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/57d7504371af

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/57d7504371af

Comment 37

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8402682 [details] [diff] [review]
[PATCH gecko v2] Account for extra time since blocking correctly r=karlt

Thanks Ryan, this applies cleanly to mozilla-b2g28_v1_3 so I'm asking for approval for this too.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 952893
[User impact] if declined: with the gaia workaround in place none in the dialer but other applications will get a broken value the first time they read AudioContext.currentTime. Since this is commonly used by Web Audio applications to generate sounds the first one played can be garbled up as we've seen on this bug.
[Testing completed]: tested on hamachi/tarako
[Risk to taking this patch] (and alternatives if risky): alterations to AudioContext.currentTime though we didn't encounter any during testing
[String changes made]: none

Comment 38

[isabelrios]

I just checked this bug on master on today's (04-09) buri build:
Gecko-f9ca77b
Gaia-650e8c2

Which in theory has the patch included. And, unfortunately there is still an issue here. Now, it is not possible to hear anything when the called party hangs up. 
When I was testing it I faced this bug 993462 but although the call screen screen is not shown, it is possible to hear the regular call tone but then nothing when the called party hangs up.

Should I wait to have bug 993462 fixed to test again or is it possible that there is something wrong with the patch?

Comment 39

[Gabriele Svelto [:gsvelto]]

(In reply to Isabel Rios [:isabel_rios] from comment #38)
> When I was testing it I faced this bug 993462 but although the call screen
> screen is not shown, it is possible to hear the regular call tone but then
> nothing when the called party hangs up.
> 
> Should I wait to have bug 993462 fixed to test again or is it possible that
> there is something wrong with the patch?

I fear this is due to bug 993462, in my testing everything worked fine.

Comment 40

[isabelrios]

Thanks Gabriele,
We will test then when the patch lands on 1.3 without being affected by that bug.

Btw, on comment 37, the patch is a gecko one but the approvals requested are gaia, would that be correct?

Comment 41

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8402682 [details] [diff] [review]
[PATCH gecko v2] Account for extra time since blocking correctly r=karlt

(In reply to Isabel Rios [:isabel_rios] from comment #40)
> Btw, on comment 37, the patch is a gecko one but the approvals requested are
> gaia, would that be correct?

No, you're right, I set the wrong flags.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 952893
[User impact] if declined: with the gaia workaround in place none in the dialer but other applications will get a broken value the first time they read AudioContext.currentTime. Since this is commonly used by Web Audio applications to generate sounds the first one played can be garbled up as we've seen on this bug.
[Testing completed]: tested on hamachi/tarako
[Risk to taking this patch] (and alternatives if risky): alterations to AudioContext.currentTime though we didn't encounter any during testing
[String changes made]: none

Comment 42

[isabelrios]

> > 
> > Should I wait to have bug 993462 fixed to test again or is it possible that
> > there is something wrong with the patch?
> 
> I fear this is due to bug 993462, in my testing everything worked fine.

You were right. Now that bug 993462 is fixed, the busy tone is heard.

But, there is still a problem here. The volume of the busy tone is still not correct. 
If the volume of the device is low, less than half of the maximum level, the busy tone seems to be correct. But, if the volume of the device is higher, the busy tone is played very loudly. 

The volume for the busy tone should be the same than the regular call tone. It is easy to compare both and see the difference when the device has the volume at the maximum level.

Please check if you can also reproduce that. I used today's (04/10) master buri build:
Gecko-e177929
Gaia-8697ff1

Comment 43

[Gabriele Svelto [:gsvelto]]

(In reply to Isabel Rios [:isabel_rios] from comment #42)
> But, there is still a problem here. The volume of the busy tone is still not
> correct. 

The issue is in fact not the volume but the channel; the tone is so loud because it's being played on the normal audio channel (like the ringtone for example), it should be played on the telephony channel instead. This is being fixed as part of bug 984498.

Comment 44

[isabelrios]

(In reply to Gabriele Svelto [:gsvelto] from comment #43)
> (In reply to Isabel Rios [:isabel_rios] from comment #42)
> > But, there is still a problem here. The volume of the busy tone is still not
> > correct. 
> 
> The issue is in fact not the volume but the channel; the tone is so loud
> because it's being played on the normal audio channel (like the ringtone for
> example), it should be played on the telephony channel instead. This is
> being fixed as part of bug 984498.

Ok, understood! We will re-test when that bug is fixed then.
Thanks Gabriele

Comment 45

[Jason Smith [:jsmith]]

We're going to wait for bug 984498 to land before we uplift this.

Comment 46

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8402683 [details] [diff] [review]
[PATCH gaia v2] Workaround for glitchy sound when playing the busytone r=etienne

Redirecting approvals. Sorry for the inconvenience Fabrice, I had missed the update to the landing procedure.

Comment 47

[Mingming ZHAO]

Hi, test the patch, the tone is still going to the speaker phone instead of the earpiece. The tone should like the DTMF tone.

Comment 48

[Juan Perez-Bedmar [:juanpbf]]

Guys, is this patch solving the problem that the sound comes out through the loudspeaker instead of from the earpiece?  
--> that is what is really blocking our cert. processes and, apart from that, we cannot allow any device to go commercial with a bug like this; it is dangerous to users. 
We need to fix this ASAP as we are in a hurry.

BR

Comment 49

[Gabriele Svelto [:gsvelto]]

(In reply to Juan Perez-Bedmar [:juanpbf] from comment #48)
> Guys, is this patch solving the problem that the sound comes out through the
> loudspeaker instead of from the earpiece?  

No, we need to fix bug 984498 for that.

Comment 50

[Preeti Raghunath(:Preeti)]

Comment on attachment 8402683 [details] [diff] [review]
[PATCH gaia v2] Workaround for glitchy sound when playing the busytone r=etienne

Clearing the flag for 1.4 as its an automatic once 1.3 is approved.

Comment 51

[Preeti Raghunath(:Preeti)]

Comment on attachment 8402683 [details] [diff] [review]
[PATCH gaia v2] Workaround for glitchy sound when playing the busytone r=etienne

Taking for 1.3 as its a cert blocker.

Comment 52

[Ryan VanderMeulen [:RyanVM]]

(In reply to Jason Smith [:jsmith] from comment #45)
> We're going to wait for bug 984498 to land before we uplift this.

I assume we're still waiting on this before uplifting?

Comment 53

[Jason Smith [:jsmith]]

Actually, let's just get this uplifted. bug 984498 is marked as a blocker, so it will get uplifted as well eventually for 1.3.

Comment 54

[Gabriele Svelto [:gsvelto]]

Cherry-picked to gaia/v1.3 fb2b8e25e8095a5db49b5eb68c74b49f180605d4 and gaia/v1.4 39b6e1cf972ffc8fafbbb294cebbd973d19967e6.

I'm leaving the v1.3/v1.4 status as affected until the gecko patch gets uplifted. Note that we're still waiting on approval for mozilla-b2g28 on that one but we can already land it on aurora.

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0de33d74936a

Pinging bajaj on the b2g28 approval for the Gecko patch.

Comment 56

[Mingming ZHAO]

Hi, the sound still comes out through the loudspeaker instead of from the earpiece.

Comment 57

[Beatriz Rodríguez [:brg]]

(In reply to Mingming ZHAO from comment #56)
> Hi, the sound still comes out through the loudspeaker instead of from the
> earpiece.
According to comment 49, you need bug 984498 implementation for that.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/4574c7242038

Comment 59

[Mingming ZHAO]

The patch of 984498 does not work well, it is even WORST. There is no sound to the user when the call is busy.

Comment 60

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Mingming ZHAO from comment #59)
> The patch of 984498 does not work well, it is even WORST. There is no sound
> to the user when the call is busy.

Hi Mingming -

In fact, this patch has been verified by other partners with TEF, and it works fine. Could you help to check again if you indeed include all the dependent patches into your code?

Thanks

Vance

Comment 61

[Mingming ZHAO]

Hi Vance,

I merged the patch of 988760, 984498 and 997701, there is no sound of busy line. But when I remove the patch of 984498 and 997701, the behavior is "the sound still comes out through the loudspeaker instead of from the earpiece."

when I remove the patch of 984498 and 997701, I try to play the busy tone when the call is active, the sound is from earpiece, but when the call is idle, the tone is from loudspeaker.

I'm not sure when receive the "BusyError" message, the call is active or idle. But according to the current behavior, the call is idle. So the tone is going to speaker instead of earpiece.

The code: https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/communications/dialer/js/telephony_helper.js#L115

else if (errorName === 'BusyError') {
            notifyBusyLine();
            displayMessage('NumberIsBusy');
          }

Comment 62

[Mingming ZHAO]

Dears,

I think the patches of 988760, 984498 and 997701 still does not solve the problem "Where is the sound output?"

Because when the Dialer APP receive the message "BusyError", the call state is disconnect, this time the "TelephonyProvider.js" will set the "gAudioManager.phoneState = nsIAudioManager.PHONE_STATE_NORMAL" (http://mxr.mozilla.org/mozilla-b2g28_v1_3/source/dom/telephony/gonk/TelephonyProvider.js#282), so the sound will output from speaker.