1039199 - [Dialer] When you put the phone on your ear, tones are not played using telephony channel

Status: VERIFIED FIXED

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

Description

[David Garcia [:davidg][retired]]

STR:
1. Make a call using the DuT to a number that is busy in another call.
2. Put the DuT on your ear.

EXPECTED:
1. The busy tone should played in the telephony audio channel like as part of the call.

OBSERVED:
3. The busy tone is played in the normal audio channel (external speaker) instead of the telephony audio channel.

Comment 1

[José Antonio Olivera Ortega [:jaoo]]

Dupe of bug 1038616?

Comment 2

[David Garcia [:davidg][retired]]

Could be. Not sure. 
As suggested by Etienne, I'm going to fix this one first and see what happens with 1038616 and 995938 next.

Comment 3

[David Garcia [:davidg][retired]]

Attachment: github PR

Comment 4

[Gabriele Svelto [:gsvelto]]

Did we regress bug 984498?

Comment 5

[David Garcia [:davidg][retired]]

Gabriele, yes, looks like bug 984498 still happens. But there is more than one problem going on here.

First, callscreen TonePlayer should be using 'telephony' channel while you are in a call, and go back to 'normal' when you are not. Currently it switches between those channels using visibilitychange event of the callscreen app. The problem is that if you put the phone in your ear during a call, it switches the screen off -> visibilitychange triggers -> it switches TonePlayer to channel 'normal' because callscreen is no longer visible -> if your phone is in silent you don't hear the tones, if it is not, you hear them in the external speaker instead of the ear one. That is the problem described in thus bug, and the patch I submitted should fix it (I hope).

The second problem is the busy tone, that I'm trying to solve in bug 1038616. The busy tone is played by the communications app (not the callscreen app), so it should not be affected by the visibilitychange thing I said above. The communications app TonePlayer is using the 'normal' channel instead of the 'telephony' channel. So if the device is silent, you don't hear anything, if the device is not silent, it uses the external speaker. 

And there is a third problem, that is, if you change the channel to 'telephony' before playing the busy tone, it works fine, it plays it in the front speaker instead of the external one. But, if the device is silent then you don't hear anything, even if the channel is 'telephony'. So I guess 984498 is regressed

Comment 6

[Etienne Segonzac (:etienne)]

Comment on attachment 8456796 [details] [review]
github PR

Thanks!

Comment 7

[Gabriele Svelto [:gsvelto]]

(In reply to David Garcia [:davidg] from comment #5)
> Gabriele, yes, looks like bug 984498 still happens. But there is more than
> one problem going on here.
> [...]

Thanks for investigating this David, some of the issues you mention (the third in particular) might be on the Gecko side too. Please file some bugs - or look if there's already some filed - on this topic and CC both me and Etienne.

Comment 8

[David Garcia [:davidg][retired]]

Master: f24de71940a6d39b5bc66a8ef6bb65ee48117fd8

Comment 9

[Maria Angeles Oteo (:oteo)]

I am also suffering this bug in 2.0 latest build so nominating this bug to be fixed in that release.

Environment info:
v2.0, hamachi
B-41
Gecko-cee7379
Gaia-aa4f795

Comment 10

[Anthony Ricaud (:rik)]

David: Étienne: Why is this patch not including new tests?

Comment 11

[Etienne Segonzac (:etienne)]

(In reply to Anthony Ricaud (:rik) from comment #10)
> David: Étienne: Why is this patch not including new tests?

I don't make contributors do the plumbing for quick fixes, we already talked about this.

I see you don't agree, please assign the follow-up adding the plumbing+tests to me, and I'll make sure to redirect the review to you next time somebody new is touching an under-tested area of the code, but no need for the passive-agressivity.

Comment 12

[Anthony Ricaud (:rik)]

Sorry it sounded passive-agressive, it was a genuine question. I do agree actually, I didn't know we don't have the plumbing for this part of the code base. I should have looked for existing tests before asking.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/a9e3b4adf1e52a3e5ee0052f48cd07f2d54bb2e6

Comment 14

[Paladin]

Attachment: Verify_video.3gp

This issue has been verified successfully on Flame 2.0,2.1

See attachment: Verify_video.png
Reproducing rate: 0/5
Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141130000204
Version         32.0
Flame 2.1 versions:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141130001203
Version         34.0