There was a regression introduced in AudioFlinger by change 24114 for suspended output:
The suspended output was not reading and mixing audio tracks.
When the phone is ringing, the A2DP output is suspended if the SCO headset and A2DP headset are the same. As the ringtone is played over the duplicated output, the fact that the A2DP output was not reading data was causing the hardware output to be stalled from time to time.
This appears to fix the sim-eng build on the gDapper build machines.
Basic problem is that LayerBuffer::OverlaySource has a constructor that
calls SurfaceFlinger.signalEvent(). SurfaceFlinger lists LayerBuffer
as a friend, but that's not enough to convince gcc that the embedded
OverlaySource class is also a friend. I don't see a way to make them
friendly, so I marked signalEvent() as public.
a new method, compostionComplete() is added to the framebuffer hal, it is used by surfaceflinger to signal the driver that the composition is complete, BEFORE it releases its client. This gives a chance to the driver to
The fix consists in locking AudioFlinger::mLock mutex in the TrackBase destructor before clearing the strong pointer to the shared memory client. The mutex is not locked in removeclient() any more which implies that we must make sure that the Client destructor is always called from the TrackBase destructor or that we hold the mLock mutex before calling deleting the Client.
Take 2. We needed to check that the usage flags are "good enough" as opposed to "the same".
This reverts commit 8f17a762fe9e9f31e4e86cb60ff2bfb6b10fdee6.
The problem comes from the fact that when the duplicated output is closed after BT headset disconnection, the OUTPUT_CLOSED notification is not sent to AudioSystem. Then the mapping between notification stream and duplicated output cached in AudioSystem is not cleared and next time a notification is played, the duplicated output is selected and the createTrack() request is refused by AudioFlinger as the selected output doesn't exist.
The notification is ignored by AudioFlinger because when it is sent by the terminating playback thread, the thread has already been removed from the playback thread list.
The fix consists in sending the notification in closeOutput() and not when exiting the playback thread.
The same fix is applied to record threads.
This is due to a regression introduced by change 24114: when no audio tracks are ready for mixing, 0s are written to audio hardware. However this should only happen if tracks have already been mixed since the audio flinger thread woke up.
Also do not write 0s to audio hardware in direct output threads when audio format is not linear PCM.
