Broadcast mastervolume intents regardless of whether the system changed the
volume. This fixes the bug where the volume LEDs stop getting updates.
TESTED = runs on Tungsten.
Change-Id: Id363da3f825934fd7785ed3d3e436f74e657b7e6
Stop ANR dialogs from appearing on devices where the ActivityManager dialogs
should not be shown. Instead, kill the process. This is preferable because the
user can't actually do anything on the device.
TESTED = runs on device with that config, simulated ANR using test app.
Change-Id: I6267000afd12ef929f0c625220184c6ab0139552
* commit 'bd26ba4871078aa85024320040de35995e90924b':
docs: update SDK and AVD Manager strings; update android tool doc and update another AVD manager screenshot and finally change "component" to "package" for SDK manager docs
Fix an issue with buffer lifecycle management which could cause audio
pops on timed outputs. There were two issues at work here.
1) During trim operations for the queued timed audio data, buffers
were being trimmed based on their starting PTS instead of when the
chunk of audio data actually ended. This means that if you have a
very large chunk of audio data (larger than the mixer lead time),
then a buffer at the head of the queue could be eligible to be
trimmed before its data had been completely mixed into the output
stream, even though the output stream was fully buffered and in no
danger of underflow.
2) The implementation of getNextBuffer and releaseBuffer for timed
audio tracks was not keeping anything like a reference to the data
that it handed out to the mixer. The original architecture here
seemed to be expecting a ring buffer design, but timed audio tracks
use a packet based design. Pieces of packets are handed out to the
mixer which then frequently will hold onto that chunk of data
across two mix operations, using the first part of the chunk to
finish a mix buffer and then using the end of the chunk for the
start of the next mix buffer. If the buffer that the mixer is
holding a piece of got trimmed before the start of the next mix
operation, it would return to its heap and could be filled with who
knows what by the time it actually got mixed. On debug builds,
they seem to get zero'ed out as they go back to the heap causing
obvious pops in presentation.
This change addresses both issues. Trim operations are now based on
ending presentation time for a chunk of audio, not the start. Also,
when the head of the queue is in flight to the mixer, it can no longer
be trimmed immediately, merely flagged for trim by the mixer when the
mixer finally does call releaseBuffer.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: Ia1ba08cb9dea35a698723ab2d9bcbf804f1682fe
and update another AVD manager screenshot
and finally change "component" to "package" for SDK manager docs
Change-Id: Iae7de7c0264d0cdff4fba0920e50e4637bcf90e0
Immedately release any TX group a player is holding upon entering the
error state. Once in the error state, the only way out for a media
player it to be completely reset (destroying the player at the
tx_player level of things). There is really no point in holding on to
a tx group once the player is in the error state.
Change-Id: If5442a32e012b5596789078b0790ed73fa842629
When an audio decoder signals a format change, we were destroying our
renderer so that a new one could be created with the new format, but
we were not updating our internal format state variables with the new
format information.
This fixes issues with AAC audio with SBR extensions; in particular
content coming from Pandora. Pandora audio is currently being
delivered as AAC-LC decoding to 22.05 KHz, but with an SBR layer which
gives 44.1 KHz. Whether or not you are going to get 22.05 or 44.1
depends on if your decoder supports SBR ("High Efficiency" profile).
Stagefright does not parse the extension sample rate present in the
ESDS; instead it reports the sample rate of the base stream (22050 in
this case). Its only when the decoder decides it can handle SBR that
you get a chance to discover that the content is actually 44.1,
information it delivers via a format change status code during read.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: I78fb89b4356004d7834629ccc82ca99c4cc7954a
Fix a mistake which came in as part of a merge conflict resolution
during code review of the recent unicast mode refactor of LibAAH_RTP.
Nop packet which were supposed to carry TS transformations for the
pause state accidentally got flagged as Flush operations. The flush
packet successfully carried the TS transformation, but also had the
undesired side effect of constantly flushing the stream.
Change-Id: I4c6aa0043fc274a1d7e880ed1d19cf277f22194b
Signed-off-by: John Grossman <johngro@google.com>
