| 379743beded881127703334e1dda2cd327ec651d |
|
29-Sep-2013 |
Zhihai Xu <zhihaixu@google.com> |
Failure to start playback on A2DP sink after connection
This is what happen:
after Headset is connected, we call start_audio_datapath which will send AVDTP_Start command to Headset,
Headset reject it with bad state. Bluedroid stack will ack failure to start_audio_datapath.
The next time we write audio data to bluetooth, we will call start_audio_datapath again to send AVDTP_Start command to Headset
Headset reject it with bad state again. Bluedroid stack will ack failure to start_audio_datapath.
When the third time we call start_audio_datapath, right at that time we receive AVDTP_Start command from Headset.
Handle AVDTP_Start command and Handle start_audio_datapath are in two different threads.
Handle AVDTP_Start command is in btu_task thread.
Handle start_audio_datapath() is in btif_task thread.
We have race condition in this case
Because when btif_task processed BTIF_AV_START_STREAM_REQ_EVT(triggered by start_audio_datapath),
it don't know we receive AVDTP_Start command which is processed in btu_task.
btif_task will send a message BTA_AV_API_START_EVT to btu_task, which will be handled by bta_av_do_start.
AVDTP_start command from headset is handled by bta_av_start_ok.
bta_av_start_ok will send BTA_AV_START_EVT with suspending true to btif_task and send AVDTP_Suspend command
to headset to suspend the AVDTP for reconfiguration purpose.
in bta_av_do_start, we will check whether the AVDTP is already started, we will know the AVDTP is already start at this time because
bta_av_do_start is also running in btu_task. We will send BTA_AV_START_EVT with success to btif_task.
In the btif_task, BTA_AV_START_EVT will be processed by btif_av_state_opened_handler:
For the first BTA_AV_START_EVT with suspending true sent by bta_av_start_ok, it will ignore it:
if ((p_av->start.status == BTA_SUCCESS) && (p_av->start.suspending == TRUE))
return TRUE;
For the second BTA_AV_START_EVT with success sent by bta_av_do_start , it will ack success to start_audio_datapath, and change to
BTIF_AV_STATE_STARTED/BTAV_AUDIO_STATE_STARTED, after receive success ack from bluedroid stack, we will start send Audio data to bluetooth.
At last we received AVDTP_Suspend response accept from Headset, we will send BTA_AV_SUSPEND_EVT to btif_task, which will be
handled by btif_av_state_started_handler. It will call btif_a2dp_on_suspended and call audio_state_cb with new audio state
BTAV_AUDIO_STATE_STOPPED.
so The state between bluedroid stack and audio data path is out of sync.
The fix is to send failure message if we know we suspend AVDTP in bta_av_do_start,
also make sure we won't miss acknowledgement for pending start if we exit opened state,
to avoid audio data path dead lock.
bug:10953908
Change-Id: I1704839977324b7c4e234eb843cddf3719e10d2c
/external/bluetooth/bluedroid/bta/av/bta_av_aact.c
|
| 77d1cb6ff904b48ee85c09a06c5e05dd0ed049b9 |
|
22-May-2013 |
Kausik Sinnaswamy <kausik@broadcom.com> |
Fix for AV lockup on local and remote start collision
Bug: 7002859
Change-Id: I6170be864b44011b98e08d7e2599021a3eec70a3
/external/bluetooth/bluedroid/bta/av/bta_av_aact.c
|
| 5ae72cf049004ac3c0f2f2bc048d1638a3b13d55 |
|
16-May-2013 |
Zhihai Xu <zhihaixu@google.com> |
Media profile drop on ending the outgoing video call and music is heard locally
receive AVDTP_Suspend response rejection which cause the A2DP disocnnected.
There is collision of AVDTP_Suspend request:
We send AVDTP_Suspend request and the headset send AVDTP_Suspend request also at the same time.
then We send AVDTP_Suspend response, but the headset send AVDTP_Suspend response rejection
with error code bad state after it receive the AVDTP_Suspend response from us.
we call bta_av_suspend_cfm twice in this case:
the first time we will call bta_av_suspend_cfm without error after receive AVDTP_Suspend request from headset.
the second time we will call bta_av_suspend_cfm with error bad state after receive AVDTP_Suspend response rejection from headset.
To fix this problem, we should ignore the AVDTP_Suspend response rejection from headset
after receive AVDTP_Suspend request from headset.
After we receive AVDTP_Suspend request from headset, the scb state will be changed to AVDT_SCB_OPEN_ST from AVDT_SCB_STREAM_ST.
but when we receive AVDTP_Suspend response rejection from headset, we should ignore it when we are in AVDT_SCB_OPEN_ST.
and also currently we already ignore AVDTP_Suspend response when we are in AVDT_SCB_OPEN_ST,
I don't know why we didn't do it for AVDTP Suspend rejection.
issue 8735903
Change-Id: I8db3ea6e7e4edfea41f255e7e29b8c7255cf3d96
/external/bluetooth/bluedroid/bta/av/bta_av_aact.c
|
| ead3cde4bac0c3e32cd31f149093f004eef8ceeb |
|
06-Feb-2013 |
Ganesh Ganapathi Batta <ganeshg@broadcom.com> |
Initial version of BLE support for Bluedroid
Change-Id: I9825a5cef9be2559c34c2a529b211b7d471147cf
/external/bluetooth/bluedroid/bta/av/bta_av_aact.c
|
| 5738f83aeb59361a0a2eda2460113f6dc9194271 |
|
13-Dec-2012 |
The Android Open Source Project <initial-contribution@android.com> |
Snapshot cdeccf6fdd8c2d494ea2867cb37a025bf8879baf
Change-Id: Ia2de32ccb97a9641462c72363b0a8c4288f4f36d
/external/bluetooth/bluedroid/bta/av/bta_av_aact.c
|