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.
Appears to have been broken by:
commit 9779b221e999583ff89e0dfc40e56398737adbb3
Author: Mathias Agopian <mathias@google.com>
Date: Mon Sep 7 16:32:45 2009 -0700
fix [2068105] implement queueBuffer/lockBuffer/dequeueBuffer properly
For some reason we don't like to have "-lpthread" globally -- it's a no-op
on device builds, but required for many host tools and all sim binaries --
so adding the use of pthread calls requires adding the library explicitly.
AudioFlinger: verify that mCblk is not null before using it in Track and RecordTrack contructors.
IAudioFlinger: check result of remote transaction before reading IAudioTrack and IAudioRecord.
IAudioTrack and IAudioRecord: check result of remote transaction before reading IMemory.
we could have several thread waiting on the condition and they all need to wake-up.
also added a debug "mTid" field in the class, which contains the tid of the thread (as opposed to pthread_t), this
is useful when debugging under gdb for instance.
we ended-up locking a Mutex that had been destroyed.
This happened because we gave an sp<Source> to the outside world,
and were called after LayerBuffer had been destroyed.
Instead we now give a wp<LayerBuffer> to the outside and have it
do the destruction.
Add a parameter to ToneGenerator.startTone() allowing the caller to specify the tone duration. This is used by the phone application to have a precise control on the DTMF tone duration which was not possible with the use of delayed messaged.
Also modified AudioFlinger output threads so that 0s are written to the audio output stream when no more tracks are ready to mix instead of just sleeping. This avoids an issue where the end of a previous DTMF tone could stay in audio hardware buffers and be played just before the beginning of the next DTMF tone.
Rewrote SurfaceFlinger's buffer management from the ground-up.
The design now support an arbitrary number of buffers per surface, however the current implementation is limited to four. Currently only 2 buffers are used in practice.
The main new feature is to be able to dequeue all buffers at once (very important when there are only two).
A client can dequeue all buffers until there are none available, it can lock all buffers except the last one that is used for composition. The client will block then, until a new buffer is enqueued.
The current implementation requires that buffers are locked in the same order they are dequeued and enqueued in the same order they are locked. Only one buffer can be locked at a time.
eg. Allowed sequence: DQ, DQ, LOCK, Q, LOCK, Q
eg. Forbidden sequence: DQ, DQ, LOCK, LOCK, Q, Q
Do not ramp volume if the first frame of a track is processed after the track was stopped.
In the case of very short sounds, the track stop request can be received by AudioFlinger just after the start request before the first frame is mixed by AudioMixer. In this case, the track is already in stopped state and initial volume is applied with a ramp for the first frame processed which should not be the case: initial volume change is always applied immediatelly.
This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
