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

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.

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.

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

triage: 1.3T+ base on the user impact

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

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

(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?

Loop Dafeng