1115304 - [FFOS7715 v2.1][AudioChannel]we can not change to speaker quickly when we hang up a call

Status: RESOLVED DUPLICATE of bug 1156664

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[jingmei.zhang]

STR:
1.play music
2.answer a incoming call
3.hang up the call

when the call ended,music will come out from earpiece  rather than speaker for about 5s.

Comment 1

[jingmei.zhang]

Attachment: test.log

This could only occur in SPRD device.I can not reproduce it in flame.

This might be caused by a delay command of stopOutput 'VOICE CALL'

Hi Wayne,can you help to give some advice for this issue?

the log is in the attachment.

Thank you so much!

Comment 2

[Wayne Chen [:xwaynec]]

Hi Jingmei,

It's a little strange because of setPhoneState has mode=3. (I think we do not use mode 3 in this case)
does Bug 1077190 commit to your branch?

May I ask sprd use mozilla 2.1 branch ?

Comment 3

[jingmei.zhang]

(In reply to Wayne Chen [:xwaynec] from comment #2)
> Hi Jingmei,
> 
> It's a little strange because of setPhoneState has mode=3. (I think we do
> not use mode 3 in this case)
> does Bug 1077190 commit to your branch?
> 
> May I ask sprd use mozilla 2.1 branch ?

Hi Wayne,

Yes of course,sprd use mozilla 2.1 branch.

BTW,I am not authorized to access bug #1077190.

Comment 4

[Wayne Chen [:xwaynec]]

Hi Jingmei, 

1. MT call ring start
12-20 15:46:04.101   124   879 V AudioPolicyManagerBase: setPhoneState() state 1

2. Pick phone up
12-20 15:46:10.391   124   879 V AudioPolicyManagerBase: setPhoneState() state 2

3. Stop phone
12-20 15:46:13.291   124   124 V AudioPolicyManagerBase: setPhoneState() state 0

but Set voip instantly, I think it's strange.

12-20 15:46:13.311   124   879 V AudioPolicyManagerBase: setPhoneState() state 3


Does SPRD change gaia or do some different in app? Becuase mode 3 doesn't need in this case.

Comment 5

[jingmei.zhang]

(In reply to Wayne Chen [:xwaynec] from comment #4)
Hi Wayne,

Yes,I could catch:
> adev_set_parameters, kvpairs : sprd_voip_start=true
when the phone is connected.and:
> adev_set_parameters, kvpairs : sprd_voip_start=false
when the connect is ended.

The music will not come out from speaker until 'sprd_voip_start=false' is set.

The issue is still exit even in monkey version(monkey version should be the one without sprd patch).

So the issue now is why voip is set.

I will check the issue in our locale first.

Thank you for your clues!!

Comment 6

[jingmei.zhang]

Hi Wayne,
in 1.4 branch the phone state is right.：
V/AudioPolicyManagerBase(  101): setPhoneState() state 1
V/AudioPolicyManagerBase(  101): setPhoneState() state 2
V/AudioPolicyManagerBase(  101):   Entering call in setPhoneState()
V/AudioPolicyManagerBase(  101): setPhoneState() in call state management: new state is 2
V/AudioPolicyManagerBase(  101): setPhoneState() state 0
V/AudioPolicyManagerBase(  101): setPhoneState() in call state management: new state is 0
V/AudioPolicyManagerBase(  101):   Exiting call in setPhoneState()


In a version without any SPRD patches,the issue still exist.

I think We still need your help for this issue.

Comment 7

[Wayne Chen [:xwaynec]]

Hi jingmei,

Could you attach 1.4 all log?
thanks

Comment 8

[jingmei.zhang]

Attachment: 1.4_test.log

Hi Wayne,

The log for 1.4 is in the attachment.

Thank you~

Comment 9

[Wayne Chen [:xwaynec]]

Hi Jingmei,


1. start phone
12-25 12:50:45.979   101   313 V AudioPolicyManagerBase: setPhoneState() state 2

2. end call
12-25 12:50:50.149   101   313 V AudioPolicyManagerBase: setPhoneState() state 0

12-25 12:50:50.149   101   313 V AudioPolicyManagerBase: getNewDevice() selected device 0
12-25 12:50:50.149   101   313 D AudioPolicyManagerBase: STRATEGY_FM: device is not fm speaker
12-25 12:50:50.149   101   313 V AudioPolicyManagerBase: setOutputDevice() output 2 device 0001 delayMs 0
12-25 12:50:50.149   101   313 V AudioPolicyManagerBase: setOutputDevice() prevDevice 0001, device 0001
12-25 12:50:50.149   101   313 D AudioPolicyManagerBase: STRATEGY_FM: device is not fm speaker
12-25 12:50:50.149   101   313 V AudioPolicyManagerBase: setOutputDevice() changing device 0001

after setPhoneState = 0, it should be getNewDevice = device 1 or 2. In my thinkg, there is maybe another streaming keep using. 


3. after 3 sec, then switch back to speaker.
12-25 12:50:53.779   101   101 V AudioPolicyManagerBase: setOutputDevice() output 2 device 0002 delayMs 0
12-25 12:50:53.779   101   101 V AudioPolicyManagerBase: setOutputDevice() prevDevice 0001, device 0002

Comment 10

[Wayne Chen [:xwaynec]]

Hi Jingmei,

I just use dolphin v1.4 today to try this problem.
But I didn't hear any music came from earpiece after hang up call.

Sincerely,
Wayne

Comment 11

[jingmei.zhang]

(In reply to Wayne Chen [:xwaynec] from comment #10)
> Hi Jingmei,
> 
> I just use dolphin v1.4 today to try this problem.
> But I didn't hear any music came from earpiece after hang up call.
> 
> Sincerely,
> Wayne

Yes,1.4 works well.the issue only occur in 2.1 in our locale.

As I said in comment6,the issue still occur even in a version without any SPRD patch!

So for the issue in 2.1,could we get something thing wrong in gecko?

Comment 12

[jingmei.zhang]

Hi Wayne,

It is the bt I catch when the phone state is set to 3:

#0  mozilla::dom::gonk::AudioManager::SetPhoneState (this=0xb09c9470, aState=3)
    at ../../../../gecko/dom/system/gonk/AudioManager.cpp:609
#1  0xb57de810 in mozilla::dom::gonk::AudioManager::HandleAudioChannelProcessChanged (this=this@entry=0xb09c9470)
    at ../../../../gecko/dom/system/gonk/AudioManager.cpp:337
#2  0xb57df3a6 in mozilla::dom::gonk::AudioManager::Observe (this=0xb09c9470, aSubject=0xb02b3130, 
    aTopic=0xb635353c "audio-channel-process-changed", aData=0x0) at ../../../../gecko/dom/system/gonk/AudioManager.cpp:359
#3  0xb5083b3a in nsObserverList::NotifyObservers (this=<optimized out>, aSubject=aSubject@entry=0xb02b3130, 
    aTopic=aTopic@entry=0xb635353c "audio-channel-process-changed", someData=someData@entry=0x0)
    at ../../../gecko/xpcom/ds/nsObserverList.cpp:100
#4  0xb5083eb4 in NotifyObservers (aSomeData=0x0, aTopic=0xb635353c "audio-channel-process-changed", aSubject=0xb02b3130, 
    this=<optimized out>) at ../../../gecko/xpcom/ds/nsObserverService.cpp:329
#5  nsObserverService::NotifyObservers (this=<optimized out>, aSubject=0xb02b3130, 
    aTopic=0xb635353c "audio-channel-process-changed", aSomeData=0x0) at ../../../gecko/xpcom/ds/nsObserverService.cpp:316
#6  0xb58286e4 in SendAudioChannelChangedNotification (aChildID=<optimized out>, this=0xacd31020)
    at ../../../gecko/dom/audiochannel/AudioChannelService.cpp:556
#7  mozilla::dom::AudioChannelService::SendAudioChannelChangedNotification (this=0xacd31020, aChildID=<optimized out>)
    at ../../../gecko/dom/audiochannel/AudioChannelService.cpp:544
#8  0xb58288bc in mozilla::dom::AudioChannelService::UnregisterTypeInternal (this=this@entry=0xacd31020, 
    aChannel=aChannel@entry=mozilla::dom::Telephony, aElementHidden=aElementHidden@entry=false, aChildID=aChildID@entry=0, 
    aWithVideo=aWithVideo@entry=false) at ../../../gecko/dom/audiochannel/AudioChannelService.cpp:305
#9  0xb5829032 in mozilla::dom::AudioChannelService::UnregisterType (this=this@entry=0xacd31020, aChannel=mozilla::dom::Telephony, 
    aElementHidden=<optimized out>, aChildID=aChildID@entry=0, aWithVideo=false)
    at ../../../gecko/dom/audiochannel/AudioChannelService.cpp:274
#10 0xb58290e0 in UnregisterAudioChannelAgent (aAgent=0xacf49ca0, this=0xacd31020)
    at ../../../gecko/dom/audiochannel/AudioChannelService.cpp:222
#11 mozilla::dom::AudioChannelService::UnregisterAudioChannelAgent (this=0xacd31020, aAgent=0xacf49ca0)
    at ../../../gecko/dom/audiochannel/AudioChannelService.cpp:211
#12 0xb5827da8 in StopPlaying (this=0xacf49ca0) at ../../../gecko/dom/audiochannel/AudioChannelAgent.cpp:139
#13 mozilla::dom::AudioChannelAgent::StopPlaying (this=0xacf49ca0) at ../../../gecko/dom/audiochannel/AudioChannelAgent.cpp:131
#14 0xb57de904 in SetPhoneState (aState=0, this=0xb09c9470) at ../../../../gecko/dom/system/gonk/AudioManager.cpp:631
#15 mozilla::dom::gonk::AudioManager::SetPhoneState (this=0xb09c9470, aState=0)
    at ../../../../gecko/dom/system/gonk/AudioManager.cpp:606

it seems the audio channel state is wrong in gecko?

What do you think?

Comment 13

[Wayne Chen [:xwaynec]]

There is a streaming_type=0 track still keep in AudioFlinger, so music will output from earpiece.
I think 'Loop' app may check first.

AudioMixer tracks: 00000003
FastMixer not initialized
Output thread 0xb5434008 stream volumes in dB:
    0:0, 1:-Inf, 2:-Inf, 3:-Inf, 4:-Inf, 5:0, 6:0, 7:-6, 8:-39, 9:-Inf, 10:0
Output thread 0xb5434008 tracks
   Name Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB    Server Main buf  Aux Buf Flags UndFrmCnt
      0    698    3 00000001 00000003       5   5120 P 3 44100     0     0  00494300 B85B15F8 00000000 0x400      8960
      1    108    0 00000001 00000003      15   6400 A 3 44100     0     0  0002AA80 B85B15F8 00000000 0x000     10880
Output thread 0xb5434008 active tracks
   Name Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB    Server Main buf  Aux Buf Flags UndFrmCnt
      1    108    0 00000001 00000003      15   6400 A 3 44100     0     0  0002AA80 B85B15F8 00000000 0x000     10880
Normal mixer raw underrun counters: partial=0 empty=0

Comment 14

[Wayne Chen [:xwaynec]]

Hi Steven,

could you help check this?
thanks

Comment 15

[jingmei.zhang]

Hi Wayne,

in AudioManager::HandleAudioChannelProcessChanged() I find such words:

> Note: If the user answers a VoIP call (e.g. calls) during the
> telephony call (GSM/CDMA calls) the audio manager won't set the
> PHONE_STATE_IN_COMMUNICATION audio state. Once the telephony call finishes
> the RIL plumbing sets the PHONE_STATE_NORMAL audio state. This seems to be
> an issue for the VoIP call but it is not. Once the RIL plumbing sets the
> the PHONE_STATE_NORMAL audio state the AudioManager::mPhoneAudioAgent
> member will call the StopPlaying() method causing that this function will
> be called again and therefore the audio manager sets the
> PHONE_STATE_IN_COMMUNICATION audio state.
So,According to the bt in comment12 & the word above,Voip is used during the call.

I would like to add logs in codes where Voip is called,can you help to give some advice?

Comment 16

[jingmei.zhang]

Hi Wayne,

 This might be caused by the codes in callscreen/js/audio_competing_helper.js:

> _ac = new AudioContext('telephony');

change the channel type 'telephony' to 'content',the issue will not exist.

this might be the different between 1.4 & 2.1.

Comment 17

[jingmei.zhang]

Add josea.

 Hi josea,

  Patch in bug1016277 might cause this issue.

  Everytime we make a call,the voip is connected.It makes the music could not come out from speaker timely when the call ends.

  Can you help to check the issue?

Comment 18

[jingmei.zhang]

Hi Vance，

Please help to check the issue,Thanks!

Comment 19

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

Hi Jingmei -

Josea might be in holiday these days, so could you wait for couple days till he is back?

Thanks

Vance

Comment 20

[jingmei.zhang]

Thanks Vance.

add Andrea.

Hi Andrea,

   can you help to check the issue?

Comment 21

[Andrea Marchesini [:baku]]

Attachment: audio.patch

I'm not able to test this patch with this STR. Maybe someone can help me?
What I suspect is that we set the phoneState to IN_COMMUNICATION because actually we have an active Telephony AudioChannel.
And the reason why we have this telephony AudioChannel is because we defer the unregistration of it for 1.5sec.

Comment 22

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Alastor, 
As talked, 
Please have a try on this patch. 
Thanks.

Comment 23

[Alastor Wu [:alwu]]

Hi, Andrea,
I tried your patch on my phone, but it resulted another error.
This situation was not related with the phone call, just about the music app.
When I played music on the app, the sound was came from the receiver instead of speaker.

Comment 24

[Andrea Marchesini [:baku]]

(In reply to Alastor Wu [:alwu] from comment #23)
> Hi, Andrea,
> I tried your patch on my phone, but it resulted another error.
> This situation was not related with the phone call, just about the music app.
> When I played music on the app, the sound was came from the receiver instead
> of speaker.

After a call? Or in general?

Comment 25

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

Hi Jingmei, if you have time, please also help to verify Andrea's patch on Comment#21

Thanks

Comment 26

[jingmei.zhang]

(In reply to Andrea Marchesini (:baku) from comment #24)

> After a call? Or in general?

in general.the music will come out from earpiece rather than a speaker.

Comment 28

[Andrea Marchesini [:baku]]

Attachment: audio.patch

Right. New patch.

Comment 29

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

Hi Jingmei -

Could you help to verify the new patch on Comment#28 again?

Thanks

Vance

Comment 30

[Alastor Wu [:alwu]]

Hi, Andrea,
I tested your patch, but the sound still came out from the receiver after ending a call.

Comment 31

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Comment on attachment 8542133 [details] [diff] [review]
audio.patch

From c30 information, this patch seems not work on flame..

Comment 32

[jingmei.zhang]

Hi Andrea，

Any update for this issue?

Comment 33

[jingmei.zhang]

Hi Vance,

 Please help to update the issue!

 Let me know if it needs any supports from SPRD side!

Comment 34

[jingmei.zhang]

When a call is connected:

01-08 14:12:25.996  1831  1831 E GeckoConsole: Content JS LOG at app://callscreen.gaiamobile.org/js/audio_competing_helper.js:71 in ach_compete: jingmei compete telephony ------>AudioContext('telephony');is established in gaia
01-08 14:12:26.006  1831  1831 I * JINGMEI * ==>: AudioChannelService::RegisterTelephonyChild aChildID:0
----->Telephony channel is registered in gecko
01-08 14:12:26.006   124   258 W audio_hw_primary: adev_set_parameters, kvpairs : sprd_voip_start=true
------> voip is set true

when the phone is disconnected:

01-08 14:13:00.486  1831  1831 E GeckoConsole: Content JS LOG at app://callscreen.gaiamobile.org/js/audio_competing_helper.js:95 in ach_leaveCompetition: jingmei leaveCompetition telephony
-------->AudioContext('telephony') is destroy in gaia
01-08 14:13:00.486  1831  1831 I * JINGMEI * ==>: AudioChannelService::UnregisterTelephonyChild aChildID:0 ------->Telephony channel is unregistered in gecko

it seems to have a delay of destroy AudioContext('telephony') in gecko
01-08 14:13:07.026  1831  1831 I * JINGMEI * ==>: AudioDestinationNode::DestroyMediaStream
01-08 14:13:07.396   124   259 V AudioPolicyService: jingmei AudioCommandThread() adding set parameter string sprd_voip_start=false, io 0 ,delay 0 ------->when AudioContext('telephony') is destroyed in gecko,voip is set false,music is resume to speaker.

So the main issue is the delay(about 7s) destroy of AudioContext('telephony') in gecko.

Who could help to give some suggestions for the above analysis?

Comment 35

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

Hi Andrea, could you help to check Comment#34 and provide some feedbacks?

Thanks

Vance

Comment 36

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

I can't found this problem on m-c trunk, but v2.1 has.

Comment 37

[jingmei.zhang]

(In reply to Randy Lin [:rlin] from comment #36)
> I can't found this problem on m-c trunk, but v2.1 has.

Hi Randy,

if modify in bug1016277 don't merged,it should not have the issue.

If you have space time,can you help to verification my guess?

Comment 38

[jingmei.zhang]

sorry,add ni Andrea

Comment 39

[William Hsu [:whsu]]

I can reproduce this issue on the build below. FYI.
As you can see, there is no sound from speaker after I hang up the call ( The video clip: 1:00~1:18 ) 
- http://youtu.be/jV10X1mmWCo

@ Build information: (Dolphin v2.1)
  ~ Gaia-Rev        2052ad921917c237f72d1f91040c0fb933c93662
  ~ Gecko-Rev       32ee81d6c8897c421880a2b9d3cc4ea4863e3170
  ~ Build-ID        20150213140751
  ~ Version         34.0
  ~ Device-Name     scx15_sp7715ea
  ~ FW-Release      4.4.2
  ~ FW-Incremental  44
  ~ FW-Date         Tue Dec 30 13:56:10 CST 2014

Comment 40

[William Hsu [:whsu]]

A regression window. FYI.

commit 2052ad921917c237f72d1f91040c0fb933c93662 ( First broken Gaia commit )
commit f8bed8295467193587951acd9d90ce37efc6cfa1 ( Last good Gaia commit )
commit ccb49abe412c978a4045f0c75abff534372716c4 ( Good Gaia commit )


*** Bug CAN be reproduced on following build ***
@ Build information: (Dolphin v2.1)
  ~ Gaia-Rev        2052ad921917c237f72d1f91040c0fb933c93662
  ~ Gecko-Rev       32ee81d6c8897c421880a2b9d3cc4ea4863e3170
  ~ Build-ID        20150213140751
  ~ Version         34.0
  ~ Device-Name     scx15_sp7715ea
  ~ FW-Release      4.4.2
  ~ FW-Incremental  44
  ~ FW-Date         Tue Dec 30 13:56:10 CST 2014


*** Bug CANNOT be reproduced on following build ***
@ Build information: (Dolphin v2.1)
 - Gaia-Rev        f8bed8295467193587951acd9d90ce37efc6cfa1
 - Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/06621922c5e8
 - Build-ID        20150224161212
 - Version         34.0
 - Device-Name     scx15_sp7715ga
 - FW-Release      4.4.2
 - FW-Incremental  eng.cltbld.20150224.200507
 - FW-Date         Tue Feb 24 20:05:19 EST 2015

Comment 41

[William Hsu [:whsu]]

Hi, Vance,

May I have your help?
I have find the regression window.
Could we assign a developer to trace this issue?

Comment 42

[Steven Yang [:styang]]

Maybe chens can help to check what's going on with the commit first. ni? chens.

Comment 43

[Sherman Chen [:chens] (inactive)]

commit 2052ad921917c237f72d1f91040c0fb933c93662 was introduced in bug 834530, and I found Gabriele already answered the question, the solution should be bug 1102814 per bug 834530 comment 135. Will follow that bug to see if that helps.

Comment 44

[Gabriele Svelto [:gsvelto]]

I just re-landed the patch for bug 1102814; please check this bug with those fixes applied.

Comment 45

[jingmei.zhang]

(In reply to Gabriele Svelto [:gsvelto] from comment #44)
> I just re-landed the patch for bug 1102814; please check this bug with those
> fixes applied.

Hi Gabriele,

  Issue seems still exist with re-landed patch in bug 1102814,need your help for a further investigation.

Thanks!!

Comment 46

[William Hsu [:whsu]]

Thanks Steven! :)
Remove NI?Vance since Steven is helping on this issue.

Comment 47

[Gabriele Svelto [:gsvelto]]

(In reply to jingmei.zhang from comment #45)
>   Issue seems still exist with re-landed patch in bug 1102814,need your help
> for a further investigation.

OK, the bug title mentions 2.1, did you uplift all the dependent patches including bug 1133449 before testing? This sounds like an audio channel management bug though so :baku and :alwu might be more helpful than me with it. From my side I've removed all the hacks we had around the callscreen and dialer so that the audio channels we set both for playing and for volume adjustments are correct.

Comment 48

[jingmei.zhang]

(In reply to Gabriele Svelto [:gsvelto] from comment #47)
> OK, the bug title mentions 2.1, did you uplift all the dependent patches
> including bug 1133449 before testing? This sounds like an audio channel
> management bug though so :baku and :alwu might be more helpful than me with
> it. From my side I've removed all the hacks we had around the callscreen and
> dialer so that the audio channels we set both for playing and for volume
> adjustments are correct.

Hi Gabriele,

Thank you for your advice.I think patch in bug 1133449 might do help for this issue.I will uplift it in our locale and then update the result :)

Comment 49

[jingmei.zhang]

Attachment: WorkAround.patch

Hi Gabriele,

Sorry to say that patch in bug 1133449 & bug 1102814 do not have some help for this issue ;(

The rootcause of this issue might be not in patch of bug 834530(perhaps by the delay destroy of AudioContext('telephony') after phone is hang up),But we could catch this issue once patch in bug 834530 is merged.

As for this issue,what we can do is:

1.improve the codes in gecko AudioContext (As a 2.1 issue,I think it is hard for the current)

2.adjust the codes in patch of bug 834530 to avoid the issue in 2.1 dolphin.

For 1,:baku and :alwu might be explain more.
For 2,I have tried to modify relevant codes in patch of bug 834530.
Gabriele,can you help to check if there would be some side effect?(I modified it according to the codes before bug 834530 patch merged).

Patch is attached in attachment,as it is made in 2.1,there might be something different from yours.

Thank you!

Comment 50

[Gabriele Svelto [:gsvelto]]

Having looked at your patch it seems that you will be switching the default channel like we did before bug 834530. IMHO that's going to cause regressions with touch tones which were fixed in bug 834530 so I wouldn't recommend it.

Comment 51

[jingmei.zhang]

Hi Gabriele,

Thank you so much for your help.

But can you help to assign a developer to trace this issue?It has been here for more than two months without a rootcause Analysised :(

Comment 52

[siiaceon]

as comment40, please help to resolve

Comment 53

[siiaceon]

very bad performance for customers , need better for further market

Comment 54

[Gabriele Svelto [:gsvelto]]

(In reply to jingmei.zhang from comment #51)
> But can you help to assign a developer to trace this issue?It has been here
> for more than two months without a rootcause Analysised :(

Quick update, I'm swamped with work right now and I don't know who might be more suitable to help here so I'm trying to get this prioritized internally so that we get it moving forward.

Comment 55

[Francisco Jordano [:arcturus] [:francisco]]

Asking for QA wanted to verify this in 2.2, we need to be sure this is not happening as well in that branch.

Dear partners, there is nothing else that Gabriele can do here, unfortunately he is already overloaded with the work for 2.2. That doesn't mean that mozilla is not going to take care of this bug but we should follow the process to have this fixed in 2.1 branch:

- Nominate for 2.1? (This bug is still not nominated, will leave that decision to you)
- :vchen (I can see that is ni) will take care of prioritizing and looking for a possible solution here.

Hopefully we will find a solution soon.

Thanks!

Comment 56

[jingmei.zhang]

As said in comment55,Nominate for 2.1.

Comment 57

[Shine(Leave from Mozilla)]

Attachment: video

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #55)
> Asking for QA wanted to verify this in 2.2, we need to be sure this is not
> happening as well in that branch.

This problem cannot be repro on latest build of Flame 2.2. After hang up the call, music can come out from speaker immediately.
See attachment: Flame2.2_video.MP4
Fail rate: 0/15

Flame 2.2 build:
Build ID               20150305002528
Gaia Revision          89af288bad6751248ff84504fa898206fee127fe
Gaia Date              2015-03-04 18:00:05
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/6d8d294aa8f3
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150305.094337
Firmware Date          Thu Mar  5 09:43:49 EST 2015
Bootloader             L1TC000118D0

Comment 58

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

ni Beatriz to comment on the severity of this bug as well

Comment 59

[Beatriz Rodríguez [:brg]]

Sorry for the delay, I just got my sample updated to yesterday build generated by partner. 
The issue is very easy to reproduce and it is covered during the certification testing phase. It is around 10 sec to change from earpice to speaker.
It could be a blocker for certification. It should be fixed and got 2.1+ to be attended properly.

I have tried to reproduced in Flame v2.1 and it is working great.

Comment 60

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

blocking 2.1s per Comment#59

Comment 61

[Steven Yang [:styang]]

Steven, I would need your team's help on this issue.

Comment 62

[Alastor Wu [:alwu]]

I will check it later.

Comment 63

[Alastor Wu [:alwu]]

There are two problems,

(1) Set phone states to COMMUNICATION 
In general, we would create an audio agent for the incoming call. In the audio_competing_helper.js, there created another agent for the "telephony" type AudioContext. Therefore, we have two telephony audio agents. When we hang up the phone, these agents didn't unregister them on the same time. When the first agent was unregistered, the second agent was still registered in AudioChannelService. 

If we called |TelephonyChannelIsActive()| at this time, we would get the wrong result. Although the call is ended, there still have an agent in AudioChannelService. That is why we would set the phone state to COMMUNICATION in AudioManager::HandleAudioChannelProcessChanged().

(2) Wrong audio routing
The "telephony" type AudioContext would create a stream to occupy the telephony audio track in AudioFlinger. The default audio routing of the telephony audio track is the receiver. Due to this stream is destroyed too slow, the music can only be playback from this track. When it destroyed, the audio routing would recover to the speaker.

Comment 64

[Alastor Wu [:alwu]]

We would get the wrong audio routing if the telephony track doesn't be destroy. 

That is because the audio policy strategy of the android is depended on the type of the audio tracks. If the telephony track exists, all the sound would come out from the receiver but not speaker.

The telephony track is destroyed by the cycle collection, so we can't decide when it be destroyed.

Therefore, I have some proposals for solving this issue.

(1) Expose a destroy function to JS
Add a function like |destroy()| in webidl, so the gaia can force to destroy audio tracks, instead of waiting the cycle collection to do that.

(2) Destroy destination stream when there is no sound
In present design, the destination stream would be pause when there is no input sound. Maybe we can delete the streams when it doesn't be used, and recreate it when there is input data again.

---

Hi, JW,
Above is my proposal for solving this issue.
Could you give me some suggestions?
Thanks :)

Comment 65

[JW Wang [:jwwang] [:jw_wang]]

(1) Which object will this destroy() function belong to? Btw, a destroy() function is not very Javascript-ish to me since Javascript relies on GC to do the clean-up.

(2) I am afraid this will break other scenarios since deleting a stream might result in a visible effect to the user.

Comment 66

[Gabriele Svelto [:gsvelto]]

Would AudioContext.suspend() help here? See bug 1094764.

Comment 67

[Alastor Wu [:alwu]]

Hi, Gabriele,
Thanks for your information!

Because this bug is only for V2.1s, I don't know whether they have a plan to land the changeset on this version...?
Another thing is, I'm not sure whether the |suspend()| indeed delete the stream of the AudioFliger or just block the DOMMedia stream.

Still thanks :) 
I will look for more details on Bug1094764, to check whether it is available for this issue.

Comment 68

[Alastor Wu [:alwu]]

Because we can't determine when the telephony track is deleted (It was deleted by the cycle collection), after discussion we prefer to use the preference to close the hacking in the audio_competing_helper.js.

Sean will help us to update the gaia patch, 
Very appreciate :)

Comment 69

[GitHub Autolander Bot]

Attachment: [gaia] weilonge:seanlee/Dialer/v2.1s/Bug1115304 > mozilla-b2g:v2.1s

Comment 70

[Sean Lee [:seanlee][:weilonge]]

Attachment: Trail Patch for v2.1s

Hi Jose,

The new setting value "telephony.audiocompeting.disabled" is for toggling audio competition, and the default value is true (disabled).

Could you help to give some suggestions for this patch?
Thank you.

Comment 71

[jingmei.zhang]

Hi Sean,

Just some of my opinion for this patch:

I am afraid issue will not be solved by the patch.It disabled the use of 'AudioContext('telephony')' in audio competition,But does not disabled the use of 'AudioContext('telephony')' in end call tone when we hang up the call.

Comment 72

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

ni Sean per Comment#71. Hi Sean, could you check Jingmei's opinion and comment?

Thanks

Comment 73

[Sean Lee [:seanlee][:weilonge]]

Hi Jingmei,

Could you share more detail about the use of 'AudioContext('telephony')' in end call tone when we hang up the call?

I found tone_player.js will use telephony channel to play key tone except AudioCompeteHelper.
https://github.com/weilonge/gaia/blob/v2.1s/shared/js/dialer/tone_player.js#L87

Comment 74

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

ni Jingmei per Comment#73. Also

Comment 75

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

Also Jingmei, if possible could you help to integrate Sean's patch and get it a try?

Comment 76

[jingmei.zhang]

Hi Sean,

When we hang up the call:

1. By call TonePlayer.playSequence([[480, 620, 250]]); End call tone is called: 
https://github.com/weilonge/gaia/blob/v2.1s/apps/callscreen/js/handled_call.js#L356

2.in playSequence,_ensureAudio()is called:
https://github.com/weilonge/gaia/blob/v2.1s/shared/js/dialer/tone_player.js#L258

3.telephony channel is used to play end call in tone _ensureAudio():
https://github.com/weilonge/gaia/blob/v2.1s/shared/js/dialer/tone_player.js#L87

Hope it could do some help ;)

Hi Vance,

I have tried the patch already,Issue still exist with the patch integrated.

Comment 77

[José Antonio Olivera Ortega [:jaoo]]

If I'm not wrong the hang up call issue raised at comment 71 is not related with the way of disabling the audio competing helper functionality. I haven't had the chance to see the patch deeply but in general it could work. I'll provide feedback on it ASAP.

Comment 78

[Alastor Wu [:alwu]]

Hi, all,
I'm checking the comment71 now. 
I will update report after finishing checking.

Comment 79

[Sean Lee [:seanlee][:weilonge]]

As far as I know, there are two modules will use AudioContext('telephony') in Gaia:
1. AudioCompetingHelper (removed in attachment 8579111 [details] [review] )
2. TonePlayer in CallScreen only

IMHO, TonePlayer.playSequence([[480, 620, 250]]); is a feature, so it should not be removed.
If Call-end tone should be played through earpiece, telephony channel is the only way.
( Audio API mentioned this. correct me if I was wrong. :P )

Thank you.

Comment 80

[Alastor Wu [:alwu]]

Hi, all,

In keypad.js, we initialize the TonePlayer with "telehpony" audio type [1]. It should be modified to "notification". The comment also mentioned that it should be changed to "notification" after fixing the Bug 1092346. (This bug is solved now) Therefore, the "telephony" audio type AudioContext is only used by the AudioCompetingHelper. If we get it off and modify the TonePlay's audio type, the issue can be solved. 

Sean also mentioned that the call-end and keypad tone should be playback through receiver. I found that even I use the "notification", the audio can still come out from the receiver.

As I know, the AudioPolicyManager will choose the routing strategy by checking the streams type in the hw audio output. If there has a "voice call" streams, it would use the STRATEGY_PHONE to set the receiver as the output device.

BUT, I observed that we would still use the receiver as output device even when there is no streams in the audio output. That confuse me. I would ask someone for more details.

CONCLUSION :
The issue can be solved by taking the AudioCompetingHelper off and modifing the TonePlay's audio type.

[1] https://github.com/weilonge/gaia/blob/v2.1s/shared/js/dialer/keypad.js#L241

Comment 81

[jingmei.zhang]

Hi All,

I conclude from the current tries that:

As log as the first AudioContext we used is not "telehpony",issue will not exist,that is if we modified codes in audio competing as:

> _ac = new AudioContext('content'); ---->any other channel except "telehpony"

I do not know why,but actually the fact is that.

Comment 82

[Alastor Wu [:alwu]]

In v2.1/2.2, we only have one MSG instance to handle all audio channel type streams, and it have already been modified in Bug 1073615.

We need to know that there is a audio driver in the MSG. This driver will create difference audio backend streams by audio channel types. The backend streams is effected our actually audio behavior in the android.

When we create AudioContext, it would use its audio channel type to create the instance of the MSG.

If we only have a instance, that means we will always get the same MSG we created at the first time, even we create other audio channel type AudioContext later. 

Therefore, in this case, if we create first the any other channels (except "telehpony") for the AudioContext, we will not possible to get the telephony MSG, even when we create telephony type AudioContext later.

Since there is no telephony MSG, means that no backend telephony streams in audio output, the issue would not happen.

Comment 83

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 8579111 [details] [review]
Trail Patch for v2.1s

Left a few comments but It looks fine in general. Thanks!

Comment 84

[jingmei.zhang]

Hi  Alastor,

It works well in flame for the same situation.

But why dolphin has such a long delay cycle collection of telephony track as mentioned in comment64&68?

Can we check from this point?

Comment 85

[Alastor Wu [:alwu]]

Hi, JingMei,
The issue can't be reproduce on the Flame is due to the Flame's hw audio outputs is more than the Dolphin's. From my observation, the Dolphin only have one hw audio outputs.

There are two conditions that the audio routing will come out from the receiver, 
Condition 1. There is a "voice call" stream in the hw audio output
 - This will change the strategy of THIS hw audio output to the receiver
Condition 2. When we answer the phone (the call state of telephony is IN_CALL)
 - This will change the strategy of ALL hw audio outputs to the receiver

In Dolphin, after hang up the call, 
- Call state = IN_NORMAL
- Music & voice call streams are all in the same hw audio output -> Match condition 1
Therefore, the audio routing strategy is the receiver.

In Flame, after hang up the call, 
- Call state = IN_NORMAL
- Voice call stream is in hw audio output 1, Music stream is in hw audio output 2 
Due to we put these streams to the different hw audio outputs, they will not affect each other. 
In hw audio output 1, the routing strategy is receiver. In hw audio output 2, the routing strategy is speaker.
That is why we can't reproduce this issue in the Flame.

Comment 86

[jingmei.zhang]

(In reply to Alastor Wu [:alwu] from comment #85)
Get it!  Thank you :)

Comment 87

[jingmei.zhang]

Hi All，

Are there any good solutions for this issue?

Compared with codes in 1.4,there is no relevant codes for telephony audio competing.and there is no hang up tone playing too……

Comment 88

[Alastor Wu [:alwu]]

Sorry, JingMei,
I don't understand what you mentioned.
You means that the issue would still be happened even there didn't have the code "audio_competing" and "hang up tone"?

So...the solution of comment80 is not workable for you?
Thanks!

Comment 89

[jingmei.zhang]

(In reply to Alastor Wu [:alwu] from comment #88)
> Sorry, JingMei,
> I don't understand what you mentioned.
> You means that the issue would still be happened even there didn't have the
> code "audio_competing" and "hang up tone"?
> 
> So...the solution of comment80 is not workable for you?
> Thanks!
Hi Alastor,
I mean issue does not reproduce in 1.4 for there is no "audio_competing" and "hang up tone".

So you mean currently the only solution is remove "audio_competing" and "hang up tone"?If so,I will modified codes in our locale.

Comment 90

[Alastor Wu [:alwu]]

Hi, JingMei,
If you don't have these code in 1.4, that means the telephony audio tracks doesn't be created, so the issue sure doesn't exist :)

Yes, I think that is the only solution for this issue, 
(1) Apply sean's patch on Comment70
(2) Modify the TonePlay's audio type.

About the second point, I need to explain that when the phone is the call state "IN_CALL", ANY audio channel would be playback from the receiver. Therefore, we don't need to use the "telephony" type at that time.