All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED DUPLICATE of bug 1156664

Status

--
major
RESOLVED DUPLICATE of bug 1156664
4 years ago
4 years ago

People

(Reporter: jingmei.zhang, Assigned: alwu)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(blocking-b2g:2.1S+, b2g-v2.1 affected, b2g-v2.2 unaffected)

Details

(Whiteboard: sprd385896)

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
Created attachment 8541148 [details]
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!
Flags: needinfo?(waychen)

Updated

4 years ago
Flags: needinfo?(waychen)
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 ?
Flags: needinfo?(jingmei.zhang)
(Reporter)

Comment 3

4 years ago
(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.
Flags: needinfo?(jingmei.zhang)
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.
(Reporter)

Comment 5

4 years ago
(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!!
(Reporter)

Comment 6

4 years ago
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.
Hi jingmei,

Could you attach 1.4 all log?
thanks
(Reporter)

Comment 8

4 years ago
Created attachment 8541387 [details]
1.4_test.log

Hi Wayne,

The log for 1.4 is in the attachment.

Thank you~
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
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
(Reporter)

Comment 11

4 years ago
(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?
(Reporter)

Comment 12

4 years ago
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?
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
Hi Steven,

could you help check this?
thanks
Flags: needinfo?(slee)
(Reporter)

Comment 15

4 years ago
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?
(Reporter)

Comment 16

4 years ago
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.
(Reporter)

Comment 17

4 years ago
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?
Flags: needinfo?(josea.olivera)
(Reporter)

Comment 18

4 years ago
Hi Vance,

Please help to check the issue,Thanks!
Flags: needinfo?(vchen)
Hi Jingmei -

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

Thanks

Vance
Flags: needinfo?(vchen)
(Reporter)

Comment 20

4 years ago
Thanks Vance.

add Andrea.

Hi Andrea,

   can you help to check the issue?
Flags: needinfo?(amarchesini)
Created attachment 8542102 [details] [diff] [review]
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.
Flags: needinfo?(amarchesini)
Attachment #8542102 - Flags: review?(rlin)
Hi Alastor, 
As talked, 
Please have a try on this patch. 
Thanks.
Flags: needinfo?(alwu)
(Assignee)

Comment 23

4 years ago
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.
Flags: needinfo?(alwu)
(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?
Hi Jingmei, if you have time, please also help to verify Andrea's patch on Comment#21

Thanks
Flags: needinfo?(jingmei.zhang)
(Reporter)

Comment 26

4 years ago
(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.
Flags: needinfo?(jingmei.zhang)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1113893
Created attachment 8542133 [details] [diff] [review]
audio.patch

Right. New patch.
Attachment #8542102 - Attachment is obsolete: true
Attachment #8542102 - Flags: review?(rlin)
Attachment #8542133 - Flags: review?(rlin)
Hi Jingmei -

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

Thanks

Vance
Flags: needinfo?(jingmei.zhang)
(Assignee)

Comment 30

4 years ago
Hi, Andrea,
I tested your patch, but the sound still came out from the receiver after ending a call.
Comment on attachment 8542133 [details] [diff] [review]
audio.patch

From c30 information, this patch seems not work on flame..
Attachment #8542133 - Flags: review?(rlin)
(Reporter)

Comment 32

4 years ago
Hi Andrea,

Any update for this issue?
Flags: needinfo?(jingmei.zhang) → needinfo?(amarchesini)
(Reporter)

Comment 33

4 years ago
Hi Vance,

 Please help to update the issue!

 Let me know if it needs any supports from SPRD side!
Flags: needinfo?(vchen)
(Reporter)

Comment 34

4 years ago
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?
Hi Andrea, could you help to check Comment#34 and provide some feedbacks?

Thanks

Vance
Flags: needinfo?(vchen)
Flags: needinfo?(slee)
Flags: needinfo?(josea.olivera)
Flags: needinfo?(amarchesini)
Flags: needinfo?(amarchesini)
I can't found this problem on m-c trunk, but v2.1 has.
(Reporter)

Comment 37

4 years ago
(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?
(Reporter)

Updated

4 years ago
Flags: needinfo?(amarchesini)
Summary: [SPRD FFOS2.1]we can not change to speaker quickly when we hang up a call → [FFOS7715 v2.1][AudioChannel]we can not change to speaker quickly when we hang up a call
Whiteboard: sprd385896
(Reporter)

Comment 38

4 years ago
sorry,add ni Andrea
Flags: needinfo?(amarchesini)

Updated

4 years ago
Blocks: 1123554

Comment 39

4 years ago
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
status-b2g-v2.1: --- → affected

Comment 40

4 years ago
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

4 years ago
Hi, Vance,

May I have your help?
I have find the regression window.
Could we assign a developer to trace this issue?
Flags: needinfo?(vchen)
Keywords: regression
Maybe chens can help to check what's going on with the commit first. ni? chens.
Flags: needinfo?(chens)
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.
I just re-landed the patch for bug 1102814; please check this bug with those fixes applied.
(Reporter)

Comment 45

4 years ago
(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!!
Flags: needinfo?(gsvelto)

Comment 46

4 years ago
Thanks Steven! :)
Remove NI?Vance since Steven is helping on this issue.
Flags: needinfo?(vchen)
(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.
Flags: needinfo?(gsvelto)
(Reporter)

Comment 48

4 years ago
(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 :)
(Reporter)

Comment 49

4 years ago
Created attachment 8570873 [details] [diff] [review]
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!
Flags: needinfo?(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.
Flags: needinfo?(gsvelto)
(Reporter)

Comment 51

4 years ago
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 :(
Flags: needinfo?(gsvelto)

Comment 52

4 years ago
as comment40, please help to resolve
Flags: needinfo?(vchen)

Comment 53

4 years ago
very bad performance for customers , need better for further market
(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.
Flags: needinfo?(gsvelto)
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!
Keywords: qawanted
(Reporter)

Comment 56

4 years ago
As said in comment55,Nominate for 2.1.
blocking-b2g: --- → 2.1?
Created attachment 8573754 [details]
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
QA Whiteboard: [MGSEI-Triage+]
status-b2g-v2.2: --- → unaffected
Keywords: qawanted
ni Beatriz to comment on the severity of this bug as well
Flags: needinfo?(vchen) → needinfo?(beatriz.rodriguezgomez)
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.
Flags: needinfo?(beatriz.rodriguezgomez)
blocking 2.1s per Comment#59
blocking-b2g: 2.1? → 2.1S+
Flags: needinfo?(chens)
Steven, I would need your team's help on this issue.
Flags: needinfo?(slee)
(Assignee)

Comment 62

4 years ago
I will check it later.
Assignee: nobody → alwu
Flags: needinfo?(slee)
(Assignee)

Comment 63

4 years ago
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.
(Assignee)

Comment 64

4 years ago
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 :)
Flags: needinfo?(amarchesini) → needinfo?(jwwang)
(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.
Flags: needinfo?(jwwang)
Would AudioContext.suspend() help here? See bug 1094764.
(Assignee)

Comment 67

4 years ago
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.
(Assignee)

Comment 68

4 years ago
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 :)
Flags: needinfo?(selee)
Created attachment 8579108 [details] [review]
[gaia] weilonge:seanlee/Dialer/v2.1s/Bug1115304 > mozilla-b2g:v2.1s
Created attachment 8579111 [details] [review]
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.
Flags: needinfo?(selee)
Attachment #8579111 - Flags: feedback?(josea.olivera)
(Reporter)

Comment 71

4 years ago
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.
ni Sean per Comment#71. Hi Sean, could you check Jingmei's opinion and comment?

Thanks
Flags: needinfo?(selee)
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
Flags: needinfo?(selee)
ni Jingmei per Comment#73. Also
Flags: needinfo?(jingmei.zhang)
Also Jingmei, if possible could you help to integrate Sean's patch and get it a try?
(Reporter)

Comment 76

4 years ago
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.
Flags: needinfo?(jingmei.zhang)
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.
(Assignee)

Comment 78

4 years ago
Hi, all,
I'm checking the comment71 now. 
I will update report after finishing checking.
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.
(Assignee)

Comment 80

4 years ago
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
(Reporter)

Comment 81

4 years ago
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.
(Assignee)

Comment 82

4 years ago
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 on attachment 8579111 [details] [review]
Trail Patch for v2.1s

Left a few comments but It looks fine in general. Thanks!
Attachment #8579111 - Flags: feedback?(josea.olivera) → feedback+
(Reporter)

Comment 84

4 years ago
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?
(Assignee)

Comment 85

4 years ago
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.
(Reporter)

Comment 86

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

Comment 87

4 years ago
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……
(Assignee)

Comment 88

4 years ago
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!
(Reporter)

Comment 89

4 years ago
(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.
(Assignee)

Comment 90

4 years ago
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.
(Assignee)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1156664
You need to log in before you can comment on or make changes to this bug.