STR: 1.Insert head phone on flame. 2.Go to Music-->play songs. 3.Receive call on flame. 4.Receive other call on flame -->merge call. 5.Click on speaker. 6.Disconnect the call. 7.Music play in speaker for 4 to 5 sec then play in headphone. expect result: Music should not play from speaker.

Hi Alastor, It seems that when the phone is disconnected,it is not the SpeakerManager which registed to AudioChannel service that actually turn the speaker off. I think it is the telephony that turn the speaker off at first,but 'Telephony::SetSpeakerEnabled' is not called when I hang up the call. when music is resumed after the call,speaker is on: 1. music is resumed: 04-21 16:25:09.120 I/* JINGMEI * ==>( 2293): AudioChannelService::CheckTelephonyPolicy AudioChannel 1 04-21 16:25:09.120 I/* JINGMEI * ==>( 2407): AudioChannelAgent::NotifyAudioChannelStateChanged state 0 2.speaker is on 04-21 16:25:10.270 I/* JINGMEI * ==>( 2293): Telephony::GetSpeakerEnabled enabled 1 I can not find out who turn the speaker off,the issue might be caused by the delay turn off of the speaker. Can you please be kind to check the issue? So sorry to trouble you:(

Perhaps something improper in stream manager or something else: 1.play music: 04-21 17:49:11.650 V/AudioPolicyManagerBase( 127): changeRefCount() stream 3, count 1 04-21 17:49:11.650 V/AudioPolicyManagerBase( 127): setOutputDevice() output 2 device 0004 delayMs 0 2.first call in and ring tone play ,music stop: 04-21 17:49:33.250 V/AudioPolicyManagerBase( 127): changeRefCount() stream 2, count 1 //play ringtone 04-21 17:49:33.250 V/AudioPolicyManagerBase( 127): setOutputDevice() output 2 device 0006 delayMs 0 04-21 17:49:34.670 V/AudioPolicyManagerBase( 127): changeRefCount() stream 3, count 0 //music stop 04-21 17:49:34.670 V/AudioPolicyManagerBase( 127): setOutputDevice() output 2 device 0006 delayMs 232 3.phone connect,ringtone stop: 04-21 17:49:37.080 V/AudioPolicyManagerBase( 127): changeRefCount() stream 2, count 0 4.the second call in : 04-21 17:49:45.600 V/AudioPolicyManagerBase( 127): changeRefCount() stream 0, count 1 // stream 0 mean voice call stream 5.speaker on: 04-21 17:49:57.740 V/AudioPolicyManagerBase( 127): setOutputDevice() output 2 device 0002 delayMs 0 6.disconnect phone: 04-21 17:50:10.030 V/AudioPolicyManagerBase( 127): changeRefCount() stream 3, count 1 // music play in speaker 04-21 17:50:10.030 V/AudioPolicyManagerBase( 127): setOutputDevice() output 2 device 0002 delayMs 0 >important!!! we can see that when phone disconnect,it has a delay about 3s to destroy voice call >stream,before voice call stream is destroied,music come out from speaker. 04-21 17:50:13.370 V/AudioPolicyManagerBase( 127): changeRefCount() stream 0, count 0 //voice call stream destroy 04-21 17:53:17.640 V/AudioPolicyManagerBase( 127): changeRefCount() stream 3, count 1 // music begin to come out from headset 04-21 17:53:17.640 V/AudioPolicyManagerBase( 127): setOutputDevice() output 2 device 0004 delayMs 0 So the question would be: Why we have a delay to destroy voice call stream when a conference call is disconnected.

Hi Alastor, I think This issue share a same rootcause as bug 1115304: the delay destroy of telephony track by the cycle collection. In Step4,when we receive the other call,we will create a AudioContext('telephony'),And when we hang up the call,cycle collection can not destroy it timely.

Hi, JingMei, Thanks for your analysis :) In Bug 1151499, I am trying to stop the audio stream of Android audio backend when the AudioContext is no sound out. If this proposal can be accept, maybe we can fix this issue & bug 1115304 and bug 1156586.

(In reply to Alastor Wu [:alwu] from comment #4) > Hi, JingMei, > Thanks for your analysis :) > In Bug 1151499, I am trying to stop the audio stream of Android audio > backend when the AudioContext is no sound out. > If this proposal can be accept, maybe we can fix this issue & bug 1115304 > and bug 1156586. Thanks! I will keep an eye on bug 1151499 & waiting for your good news to solve them ;)

Hi Alaster - Any luck on the proposal you mentioned in Comment#4? Thanks!

Hi, Vance, The idea mentioned on Comment4 seems not a good solution. I am still finding another way to fix it.

Hi, all, Sorry to bother you guys, here I encounter some problems need your help. It seems that we have many errors are caused by the occupancy of the audio back end stream. In this issue & bug1115304, the telephony stream would result the audio coming out from the speaker. In the bug1156586, the ring stream would mute all other streams except the STRATEGY_SONIFICATION streams. [1] However, we don't have any methods to suspend audio backend streams in v2.1. It's also not appropriate to auto stop the audio backend streams when they haven't any coming input sound. [2] In addition, we don't have multiple MSG on v2.1. It's very important. It means that we can't manage difference audio backend streams at the same time. --- Here I want to propose a workaround to solve this problems. For this issue and bug1115304, I want to forbid to generate the telephony back end stream in v2.1. That is not to use the telephony backend stream as the AudioDriver of the MSG. As I known, since the sound is directly come out from the modern instead of the Gecko decoding module, the telephony stream doesn't have any substantial functionality. It seems that we might use other stream to replace it. If we do so, the output routing strategy can also be decided correctly. We can output audio to the receiver by checking the phone call state. But I don't sure whether my understanding is fully correct. Maybe there is another effect of the telephony back end stream? Second, I don't have any good ideas about the bug1156586. As I mentioned, there is only one MSG, we shouldn't arbitrarily stop the AudioDriver , since there might exist many different type streams in the same MSG. --- How do you guys think about that? Could you give me any suggestions? Very appreciate for your help :) --- [1] In Android AudioPolicyManager, it would mute the streams which isn't the STRATEGY_SONIFICATION, when we play the STRATEGY_SONIFICATION streams and the output device is the headset/headphone. I assume that the Android want to emphasize this type audio. The alarm and ringtone are STRATEGY_SONIFICATION, and the notification is STRATEGY_SONIFICATION_RESPECTFUL. You can regard them as the same. [2] The reason why we should keep audio stream alive https://bugzilla.mozilla.org/show_bug.cgi?id=1151499#c20

Not really my thing, sorry

(In reply to Alastor Wu [:alwu] from comment #8) > Here I want to propose a workaround to solve this problems. > > For this issue and bug1115304, I want to forbid to generate the telephony > back end stream in v2.1. That is not to use the telephony backend stream as > the AudioDriver of the MSG. > > As I known, since the sound is directly come out from the modern instead of > the Gecko decoding module, the telephony stream doesn't have any substantial > functionality. It seems that we might use other stream to replace it. This sounds like it would work. We are using the Telephony channel for the dialer only on 2.1, right? Can the MSG still be interrupted by the modem? > If we do so, the output routing strategy can also be decided correctly. We > can output audio to the receiver by checking the phone call state. > > But I don't sure whether my understanding is fully correct. Maybe there is > another effect of the telephony back end stream? You'd have to check, I don't know. baku, do you know if the telephony backend is special or something ?

(In reply to Paul Adenot (:padenot) from comment #10) > This sounds like it would work. We are using the Telephony channel for the > dialer only on 2.1, right? Can the MSG still be interrupted by the modem? > I think that the telephony channel is also used in m-c. As I know, the purpose of using the telephony channel in dialer is to let the sound out from the receiver. However, if we are in call, any sound would be out from the receiver, so I think we can use other types to replace it. The changing of audio backend stream does not effect the behavior of the MSG.

This patch is to forbid the usage of the telephony backend stream. Try-server result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=d5a871e3abd9

Hi Alastor, should we ask JingMei to verify the patch as well? Thanks

Hi,Alastor, I have verified the patch,but seems to cause another issue: when conference call is hang up,we could hear music from speaker Immediately,then there is no sound both in speaker & headset,then after a while music come out from headset. HOw does the patch work in your side? One more question: > aChannel = (aChannel == AudioChannel::Telephony) ? AudioChannel::Ringer : aChannel; Why do you set it to AudioChannel::Ringer other than other audio channel?

Hi, JingMei, Could you provide the log for me? Because I can't merge the call in my phone, I used the bug1115304 to verify my patch. Actually, my patch is not a good method. I just choose the high priority channel to prevent the interruption. Thanks :)

Hi Alastor, Log is in the attachment,it is 09:04 when issue occur.I catch the log in a dolphin device. Thanks!

Hi Alastor, the issue is caused by the waiting tone play when the second call in. When we go to play waiting tone,'this._ensureAudio();'is used to create a AudioContext('telephony'), Here is my opinion: 1>set the waiting tone type to another one other than 'telephony'? 2>I have not find the destroy of AudioContext('telephony') when we answer the second call,Perhaps we should destroy the waiting tone audiocontext when call is answer?

Hi, JingMei, Could you help me verify this patch? I think the problem might be resulted by the ringer backend stream. Since the ringer/alarm/notification would affect the output routing during using the headset. Therefore, in this patch, I used the music backend stream to replace the telephony backend stream. And I mentioned in previous comment about "high priority channel to prevent the interruption." is wrong, because the interruptions only happen between the Gecko audio channel types. (we only modify the backend stream type) I think this patch might work. I tried on bug1115304, and it works well. Thanks! -- Try-server result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=cce5d2e3207b

About you questions, (1) I prefer to modify the gecko behavior, because we can't control who will use the telephony type. (2) We don't have any function to destroy the AudioContext in v2.1. Even we set the AudioContext to null, the AudioContext can't be release immediately. ex. bug1115304

Hi Alastor, I have verified the patch here,It could prevent the music come out from the speaker,but when call hang up,we have to wait for 3~5s to hear the sound from the headphone. What's more,You do not have to merge the call to check this issue,as long as phone waiting tone is played, issue will occur.You can check patch in your locale then ;)

Hi, JingMei, > I have verified the patch here,It could prevent the music come out from the > speaker,but when call hang up,we have to wait for 3~5s to hear the sound > from the headphone. Does this still happen on the conference call? Cause I tested on single call, it doesn't happen. > What's more,You do not have to merge the call to check this issue,as long as > phone waiting tone is played, issue will occur.You can check patch in your > locale then ;) What is the wait tone? Is the sound like "you phone is connecting, please wait"? I am not understand the whole reproduce steps without merging call, could you please describe again? Thanks :)

Close this bug because we wouldn't land the code for v2.1.