996187 - [B2G][Tarako][Dialer] The Tarako will lose audio after accepting a call through 'Call waiting'

Status: RESOLVED DUPLICATE of bug 993564

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[demerick]

Attachment: BT_callWaiting_logcat

Description:
If the user is in a call with a Bluetooth headset connected and a second call comes in, accepting the call (call waiting) will cause the Bluetooth headset to lose audio.

After the second call hangs up and the first call is taken off hold the Bluetooth headset will have no audio.

Hanging up the first call and answering a new call will bring back audio to the Bluetooth headset.

Repro Steps:

Pre-req - Bluetooth headset, Tarako Device Under Test (DUT), two other phones (A & B)

1) Update a Tarako to BuildID: 20140414004001
2) DUT: From home screen Tap 'Settings' > 'Call Settings' > Enable Call waiting
3) DUT: Pair a Bluetooth headset with this device
4) Phone A: Call the Tarako DUT
5) DUT: Answer the call and verify audio through the BT headset
6) Phone B: Call the Tarako DUT
7) DUT: Answer the call, the BT headset will no longer have audio
8) DUT: Hangup the second call

Actual:
BT headset will still have no audio with one active call and none on hold

Expected:
BT headset should have audio during and after call waiting

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140414004001
Gaia: 0e7f21e61625b75a9149480cd5a259211549f020
Gecko: 3b02811c314a
Version: 28.1
Firmware Version: SP8810

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/10789/
See attached: logcat

Comment 1

[demerick]

After further investigation this issue appears to occur due to Call Waiting and not just Bluetooth headsets.

The summary has been updated to reflect this, STR will still reproduce this issue.

Comment 2

[demerick]

This issue does not reproduce on the Buri 1.3 MOZ RIL

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140414004002
Gaia: 8b92c56267fe50772095f1f25d6cc1f9c9966eb4
Gecko: 3e26908fca71
Version: 28.0
Firmware Version: v1.2-device.cfg

Call waiting works as expected on the Buri, audio is not lost.

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Star,
Can you help to check audio path part? Because during 2nd call, Bluetooth headset audio link won't be dropped off, so I suspect this is related to audio path

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3T+ base on the user impact

Comment 5

[Star Cheng [:scheng]]

I will investigate weather the Audio Policy HAL is correct or not.

Comment 6

[Star Cheng [:scheng]]

There is audio problem on call waiting tone. Please see the comment of another bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=993564#c34

Comment 8

[Star Cheng [:scheng]]

(In reply to Star Cheng [:scheng] from comment #7)
> 
> *** This bug has been marked as a duplicate of bug 993564 ***

I try to analysis the flow in the log, it should be correct. The waiting tone is routed to SCO output device.


I/AudioStream(   83): [star] aAudioChannelType 0 cubeb stream_type 1 -> [star] waiting tone : audiochannel (AUDIO_CHANNEL_NORMAL) -> CUBEB_STREAM_TYPE_SYSTEM

D/AudioPolicyManagerBase(   88): [star] setOutputDevice() output 1 device 20 delayMs 0 -> [star] device 0x20 -> AUDIO_DEVICE_OUT_BLUETOOTH_SCO

V/AudioPolicyManagerBase(   88): setOutputDevice() setting same device 20 or null device for output 1
W/audio_hw_primary(   88): open pcm vplayback in

Hi, James

Could you check weather it's correct or not?

Comment 9

[James Zhang (Spreadtrum)]

Loop Dafeng