Closed Bug 872054 Opened 7 years ago Closed 7 years ago

[Inari] Busy line tone is heard through the speaker

Categories

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

x86_64
Windows 7
defect
Not set
normal

Tracking

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

RESOLVED FIXED
1.0.1 Cert2 (21may)
blocking-b2g tef+
Tracking Status
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: isabelrios, Assigned: gtorodelvalle)

References

Details

(Whiteboard: [required_last_cert_round] [status: needs review] IOT)

Attachments

(1 file)

Device Inari/Ikura
Build id: 20130514090719
AU V1.01.00.01.019.105

PROCEDURE
1. From Inari call to a busy number (or call to a number which rejects your call)
2. Listen to the busy line tone

EXPECTED
The busy line tone is heard with a regular volume

ACTUAL
The busy line tone is heard through the speaker

This is a critical bug for certification. Adding dep and nominating it
Depends on: 867065
blocking-b2g: tef? → tef+
Busy tone is played by Gaia so adding gtorodelvalle who implemented this feature.
Flags: needinfo?(gtorodelvalle)
Please let us know if you're not the right assignee gtorodelvalle.
Assignee: nobody → gtorodelvalle
Target Milestone: --- → 1.0.1 Cert2 (28may)
Whiteboard: IOT → [status: needs patch] IOT
I am, I am ;-) Thanks!
Flags: needinfo?(gtorodelvalle)
Attached file Associated PR.
Sorry for the delay but this bug almost drove my crazy ;-999

The patch included solves the problem. This is, the busy tone is now played on the ear speaker. Anyhow, I observed a colateral issue I was trying to circumvent. The problem is that if the user makes a call to a busy line and just afterwards dials a new number, the key tones are played on the ear speaker for some seconds until they are played by the main speaker (so to call it).

(Technical info for Etienne) In advance, this has no sense since the Audio object created by tone_player.js (this file is linked by oncall.html) on which I set the mozAudioChannelType to 'telephony' should be destroyed once the oncall.html window is closed, but it seems to have influence on the other Audio object created also by tone_player.js (this time as a consequence of the linking by index.html, the main Communication app HTML file). I have tried almost any imaginable option (forcing the creation and destruction of the Audio objects, forcing to have only 1 Audio object in the whole Communications app, setting and unsetting the mozAudioChannelType, etc.) with no success. Should we file a bug to the platform? It seems there are no related bugs as far as I have been able to see.
Attachment #750505 - Flags: review?(etienne)
Platform bug 813426 could be related with this one although in our case we are supposed to instantiate Audio objects in distinct scopes. And as I said, after some seconds everything starts to work as expected playing the key tones on the main speaker.
Whiteboard: [status: needs patch] IOT → [status: needs review] IOT
Comment on attachment 750505 [details]
Associated PR.

Wait, don't we want _all_ the tones played during a call to be played on the telephony channel?

If yes I'd much rather have a simple |setChannel| method on the |TonePlayer| and call it _once_ when we initialize it if we're "oncall".

If not, we need to keep the precedent mozAudioChannelType value in a private instance variable in order to put back the channel as it was once the sequence is done playing.
Attachment #750505 - Flags: review?(etienne)
Whiteboard: [status: needs review] IOT → [required_last_cert_round] [status: needs review] IOT
Hi Etienne, yeah in fact that was a previous option I tried: a setAudioChannelType() method on TonePlayer but it did not convince me ;-) The main reason was to avoid creating the Audio object instance if it is not needed and postpone its creation all we can (we create an Audio object instance for the ring tone but that it a different one). Right now, in the case of oncall.js, the Audio object instance is created when TonePlayer.playSequence() is called (via the TonePlayer.ensureAudio() function). If we use the setChannel() function we should be sure that the audio is created there if it does not exists (it is as simple as invoking ensureAudio() from setChannel() before setting the channel :-) ) In oncall.js we would have something like this:

TonePlayer.setChannel('telephony'); // To postpone its creation as much as possible.
TonePlayer.playSequence(sequence);

Instead of:
TonePlayer.playSequence(sequence, 0, 'telephony'); // As proposed in my patch.

Do you still prefer the setChannel option? No problem since it is straight-forward ;-)
Flags: needinfo?(etienne)
As commented on IRC, we have included a setChannel() function in TonePlayer. The PR is already updated including this changes: https://github.com/mozilla-b2g/gaia/pull/9818
I merged this onto master, before I realised that it wasn't r+'d
master: 57568a2

Backed out with: 94e5adf

Sorry for the noise!
Comment on attachment 750505 [details]
Associated PR.

Commented on github.
We misunderstood each other on IRC there is still a small change to make to this patch.

Please don't forget to set the r?etienne flag here once the patch is updated otherwise it doesn't get on my radar.
Flags: needinfo?(etienne)
Comment on attachment 750505 [details]
Associated PR.

r=me (d21626efd42174d25046daf338c0916b711c1222)
Attachment #750505 - Flags: review+
https://github.com/mozilla-b2g/gaia/commit/619d7ec87dce1aaecb82b6100662c304183077bd
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
This patch causes a regression:
The tone would output through speaker when earphone is plugged and "not during call".
What we should do here isn't set ringer channel to it but the normal channel.

The channel of dtmf tone has been set to ringer in bug A and roll back in bug B because the same reason. Sorry I forgot the bug number..

Creating a followup bug to fix this per partner request.
BTW,
you couldn't set an audio element to different channel if you'd set it once. This is a gecko limitation. So if you want to 'change' the mozAudioChannelType, you should destroy it and have a new one.
Good to know! ;-) Thanks :alive
You need to log in before you can comment on or make changes to this bug.