d3fc8ac6c5
The problem comes from a deadlock with AudioPolicyService mutex: When the second ringtone starts, this mutex is locked by AudioPolicyService::startOutput() which in turn calls setParameters() to change the output device. Audioflinger::ThreadBase::setParameters() signals the parameter change to the AudioFlinger mixer thread and waits for a condition indicating that the parameter change has been processed. At the same time, the mixer thread detects that the audio track corresponding to the first ring tone has been killed and calls its destructor. This calls AudioPolicyService::releaseOutput() which tries to lock the AudioPolicyService mutex. If this happens before the mixer thread can process the setParameters() command we are deadlocked. The deadlock ends because setParameters() uses a timeout when waiting for the condition. This regression was introduced by change 33736 fixing issue 2265163. The fix consists in calling AudioPolicyService::releaseOutput() from Track::destroy() instead of from Track destructor: as detroy() is never called from the mixer thread loop (as opposed to the destructor) the deadlock described above cannot occur. |
||
|---|---|---|
| .. | ||
| audioflinger | ||
| binder | ||
| surfaceflinger | ||
| ui | ||
| utils | ||