Closed Bug 1039199 Opened 5 years ago Closed 5 years ago

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

Categories

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

Other
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: davidg, Assigned: davidg)

References

Details

Attachments

(2 files)

46 bytes, text/x-github-pull-request
etienne
: review+
Details | Review
4.89 MB, video/3gpp
Details
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.
Blocks: 995938, 1038616
Assignee: nobody → david.garciaparedes
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.
Attached file github PR
Attachment #8456796 - Flags: review?(etienne)
Did we regress bug 984498?
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 on attachment 8456796 [details] [review]
github PR

Thanks!
Attachment #8456796 - Flags: review?(etienne) → review+
(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.
Status: NEW → ASSIGNED
Master: f24de71940a6d39b5bc66a8ef6bb65ee48117fd8
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
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
blocking-b2g: --- → 2.0?
David: Étienne: Why is this patch not including new tests?
Flags: needinfo?(etienne)
Flags: needinfo?(david.garciaparedes)
(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.
Flags: needinfo?(etienne)
blocking-b2g: 2.0? → 2.0+
Whiteboard: [DUPEME]
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.
Flags: needinfo?(david.garciaparedes)
Attached video 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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.