1230045 - [FFOS 2.2][audiochannel] the abnoraml call state by AudioManager::HandleAudioChannelProcessChanged()

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: AudioChannel, defect, P2)

Description

[Seil Park]

We captured adb log (AudioManager) during the call ending
The flow is the below:
1. "mPhoneState" is assigned "PHONE_STATE_NORMAL" by SetPhoneState()
2. mPhoneAudioAgent->StopPlaying() and unregistering telephony channel.
3. called HandleAudioChannelProcessChanged()
4. "telephonyChannelIsActive" is ative status currently.
5. So, setphonestate is changed PHONE_STATE_IN_COMMUNICATION.

This structure has risk that the audio routing can be blocked.

11-19 14:33:31.660   329   329 I AudioManager: SetPhoneState aState = 2, mPhoneState = 2
11-19 14:33:31.690   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=2
11-19 14:33:31.690   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=2
11-19 14:33:31.790   329   329 I AudioManager: SetPhoneState aState = 0, mPhoneState = 2
11-19 14:33:31.790   324  1586 D AudioPolicyManager: setPhoneState() state 0
11-19 14:33:32.020   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=0
11-19 14:33:32.020   329   329 I AudioManager: SetPhoneState aState = 3, mPhoneState = 0
11-19 14:33:32.030   324  3983 D AudioPolicyManager: setPhoneState() state 3
11-19 14:33:32.270   324  3983 V AudioPolicyManager: setPhoneState() in call state management: new state is 3
11-19 14:33:32.380   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=3
11-19 14:33:32.380   329   329 I AudioManager: SetPhoneState aState = 3, mPhoneState = 3
11-19 14:33:32.380   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=3
11-19 14:33:32.380   329   329 I AudioManager: SetPhoneState aState = 3, mPhoneState = 3
11-19 14:33:32.380   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=3
11-19 14:33:32.380   329   329 I AudioManager: SetPhoneState aState = 3, mPhoneState = 3
11-19 14:33:32.480   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=3
11-19 14:33:34.500   329   329 I AudioManager: HandleAudioChannelProcessChanged mPhoneState=3
11-19 14:33:34.500   329   329 I AudioManager: SetPhoneState aState = 0, mPhoneState = 3
11-19 14:33:34.500   324   324 D AudioPolicyManager: setPhoneState() state 0

Comment 1

[Seil Park]

Hi, mchen.
We have dicussed about audiochannel issues in seoul. one of them is the call state issues. 
We use qcril, not mozril. So the flame version cannot be reproduce like the these log.
However, you need to improve this flow for not receving the abnormal call state in v2.2.

Comment 2

[Marco Chen [:mchen]]

(In reply to Seil Park from comment #0)
> 1. "mPhoneState" is assigned "PHONE_STATE_NORMAL" by SetPhoneState()
> 2. mPhoneAudioAgent->StopPlaying() and unregistering telephony channel.
> 3. called HandleAudioChannelProcessChanged()
> 4. "telephonyChannelIsActive" is active status currently.

I am wondering to know why there is still a existed telephony channel since mAudioChannel inside AudioManager was called to stop already.

I suspect this additional telephony channel is from audio element with telephony channel type in Dialer App. Therefore it might be the timing issue between Dialer App (audio element with telephony type), RIL::SetPhoneState and AudioManager::mPhoneAudioAgent.

Dialer App (audio element with telephony type) is a workaround for VoIP / WebRTC call in V2.2.

By the way, I left MoCo already. So would suggest you contact to Black Wu (Engineering Manager of FxOS Media Team).

Comment 3

[Seil Park]

Thanks your reply.
I heard that it dosen`t support any more firefox OS recently. I am wondering that this sequence would be happen another problum. First of all, it dosen`t have the plan to develop v2.2, I will close this issue.