This lets us avoid a Binder roundtrip to the system process during
volume changes. Previously volume change would be staged at key-down,
then applied at key up in tandem with playback of the sonic feedback
about volume key presses. The reason for this two-stage handling was
to defer playback of the sound [at the target volume] while the volume
key was being held for repeat.
On some devices volume is always sent as key down/up pairs rather than
down-repeat-up sequences. On these devices it is more efficient to
apply the new volume immediately during down handling, and have the
up handling be a no-op. This CL adds a configuration resource item
selecting this new fast path.
Bug 6433943
Change-Id: Icffa56e958243b841d514e2fe4609ba3a7b20f14
The desc.txt file can now mark parts as 'must finish cleanly' by using
'c' as the part line prefix rather than 'p'. If so indicated, if the
bootanimation is asked to quit it will do so only after waiting to
finish that part.
I considered either making init.c service killing smarter or promoting
bootanim to be a bindable service with a requestExit method. However,
these changes are probably too big/risky given our ship date. So
I used a property as a mailbox between SurfaceFlinger and bootanim.
Change-Id: I40b219c9117c97c3fc94855059ea13fe4ceb3d2b
DO NOT MERGE
this change must be hand-merged into master due to directory
restructuring.
Don't perform the end PTS calculation for each buffer during trimming.
Instead, only calculate the ending PTS of a buffer if there is no next
buffer in the queue. This optimization assumes that the buffers being
queued are in monotonic media time order (a fair assumption for now)
and that the timestamps in the audio are contiguous (not a requirement
for this API, but a reality of how it is being used right now).
In the case where the audio is discontinuous on purpose, it is
that this optimization will cause the system hold one extra buffer
which it could have safely trimmed. It should not be much of an issue
since in real life the audio is almost always contiguous, and as long
as the media clock is running and the mixer is mixing, the buffer will
be used up and discard as part of the normal flow anyway.
Change-Id: I00061e85ee7d5651fcf80751646c7d7415894a14
Signed-off-by: John Grossman <johngro@google.com>
DO NOT MERGE
this change must be hand-merged into master due to directory
restructuring.
Fix issues with continuity threshold handling; notably
+ If the steady-state continuity threshold is exceeded, be sure to
clear the on-time flag. Failure to do this will result in the
system picking a new mix point which simply satisfies the
steady-state continuity threshold instead of the startup threshold.
Since we are putting a discontinuity in presentation anyway, we
really want to pick a perfect point, not just an OK point.
+ Tighten the steady-state continuity threshold. It was currently set
to 100mSec which is enormous. 4mSec (the new setting) is much more
appropriate. On systems with a VCXO (like tungsten) this should
never be wrong by more than a sample. If TimedAudioTracks are ever
to be used on VCXO-less systems, this threshold should probably be a
a parameter configurable by applications on a track by track basis
so they can make the tradeoff between allowed error and frequency of
disruptive corrections.
+ Reset the on-time flag if the mixer provides no PTS during a mix
operation. This makes for a convenient way for the HAL to reset
timed tracks when it makes changes for delay compensation across
multiple outputs.
Change-Id: I2cb23de5a3d1f75618abc1c8ab903db883837aa8
Signed-off-by: John Grossman <johngro@google.com>
* commit '3d467946b2950c6a5e4946c49a33cf4c8d68df20':
Updated "Making your App Location Aware" class to include information on location provider enable check.
