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

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

How is this bug any different than bug 984498?

(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.

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

(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.

(In reply to Vance Chen [:vchen][vchen@mozilla.com] 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.

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.

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

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.

(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.

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

(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.

(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?

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.

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 :)

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.

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.

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.

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.

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 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 :))

(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 :)

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?

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

(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.

(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 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.

(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.

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

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

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 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

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.

(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 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

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?

(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.

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 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

> > > > 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

(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.

(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

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

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.

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

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

(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 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 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.

(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?

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.

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.

https://hg.mozilla.org/releases/mozilla-aurora/rev/0de33d74936a Pinging bajaj on the b2g28 approval for the Gecko patch.

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

(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.

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

(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

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'); }

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.