le_audio/client_audio: Fix deadlock on Stop()
During the Stop() call, `send_audio()` may still be triggered from
the other thread. Stop() call locks the mutex and waits for the periodic
task to end, while the periodic task might already be waiting for the same
mutex to be released so that it could sink the audio samples with
OnAudioDataReady() callback.
Bug: 150670922
Tag: #feature
Test: atest --host bluetooth_le_audio_test
Sponsor: jpawlowski@
Change-Id: If3653077bb11bd3e4c7034ce727597c9e7250b6f
diff --git a/system/bta/le_audio/client_audio.cc b/system/bta/le_audio/client_audio.cc
index 1e69c85..7154a70 100644
--- a/system/bta/le_audio/client_audio.cc
+++ b/system/bta/le_audio/client_audio.cc
@@ -315,12 +315,13 @@
sinkClientInterface->StopSession();
le_audio_sink_hal_state = HAL_STOPPED;
- std::lock_guard<std::mutex> guard(sinkInterfaceMutex);
- localAudioSinkReceiver = nullptr;
if (CodecManager::GetInstance()->GetCodecLocation() == CodecLocation::HOST) {
stop_audio_ticks();
}
+
+ std::lock_guard<std::mutex> guard(sinkInterfaceMutex);
+ localAudioSinkReceiver = nullptr;
}
const void* LeAudioClientAudioSource::Acquire() {
