Fixed problem in AudioTrack::restoreTrack_l() causing a permanent
failure if the IAudioTrack interface to AudioFlinger could not be
restored at the first attempt.
Change-Id: I039d4fe2dca8d3baf71f1a6c51119f27a67b6611
The Metadata class doesn't actually seem to be used with anything
in the SDK, and the API probably needs some work, so hide it.
Change-Id: Ifecf49130b90cbb4c588ad8104f1e7957978f789
Assume for now that all chunks are the same size, i.e. have the same number of
samples.
Change-Id: Ib8a7dfeb16cc3e5be199ff9d98b68dd0b9c23eb8
related-to-bug: 5279872
So that we don't accidentally identify a .avi file containing an mp3 track as
an mp3 file.
Change-Id: I73495b80cbb5bc1007bf810f2db453c9f175171b
related-to-bug: 5288189
MTS tests have hardcoded video framerates.
MTS can query the video framerate supported by device via
Camcorder profiles and use.
Change-Id: I61666df6af58eaba46f7366521cc114184cb4ac5
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
The list of directories to skip are configurable via setprop.
The main motivation is that some test data folder takes long time
to scan, and media scanner may compete for CPU time against perf
tests therefore skewing the results.
Bug: 5263115
Change-Id: I568213e2a4babf6033021c1d336ef0347c0e3315
Because we request 400x240 thumbnails. 100 thumbnails needs 38M,
which is too much. Change it to 70 now.
Also handle the case if the thumbnail callback throws exception.
Change-Id: Iac4ee72f308b7c7a6ae860983197601cf89bee8f
The problem is that any app can change the audio mode and override
a mode previously set by another app. If two apps (gTalk and Phone) compete
for audio mode ownership, there is no mechanism to maintain coherency
in the actual audio mode selected.
Added a mechanism in AudioService to manage an audio mode request stack.
Any app requesting a mode different from NORMAL enters at the top of the stack
and the requested mode is applied. When an app sets mode back to NORMAL, it exits
the stack and the new mode corresponding to the request at the top of the
stack (if any) is applied.
Change-Id: I68d1755d0922f680df4a19bfc5ab924f5a5d8ccd
Do not force wake up the AudioTrack thread every 10ms if no timed
events (loop, markers..) have to be processed.
This will help reduce power consumption.
Change-Id: Icb425b13800690008dd07c27ffac84739e3dbba3
The queuebuffer could return early due to timestamp issues. Need to set
the geometry even in that case.
Change-Id: I04d7cd1df3996d640c269285398c0042923ba920
Otherwise it'll trigger a division-by-zero exception since the audio sample rate
is as yet unknown.
Change-Id: I0793aa7c1c348ffa2611272bb646eff6ecf6ff53
related-to-bug: 5242451
fortunately in all our supported audio encodings we can treat every frame as
a keyframe.
Change-Id: I32f21d0077bbae7ef9efe725dd351baf531179e2
related-to-bug: 5263837
the media extractor failed to initialize (malformed or unsupported content)
Change-Id: Icfad4e9eeb8d6713ad12eee7979ab30b696c06e0
related-to-bug: 5263840
The problem occurs when activating or deactivating A2DP connection
while SoudPool has a channel active. This can happen quite frequently now
that the UI sound effects are enabled by default.
If PCM data is remaining in the AudioTrack buffer when it is restroyed and
re-created on the new AudioFlinger output thread, this data is flushed.
As a consequence, no underrun or request for new data callback is sent to
SoundPool and the sound channel remains active for ever as the end of the
sample is never detected.
Change-Id: I13e0c11e4ce3f83bff7f58d347ca814b6a86712b
The test was making EGL calls once disconnected. Instead of calling
"disconnect" directly on the Surface, and EGL calls should be made to that
effect.
Change-Id: I21468ac8cbc2cb3145a49269e32a884736cd452e
This change removes the MediaPlayer#setTexture method. It has been
replaced with MediaPlayer#setSurface.
Change-Id: Iaecbbac7629d7092883f270694c5c67391f4ed6c
Both ::getSize and ::read call into lseek64, if this happens simultaneously
from multiple threads the results are undefined if not properly serialized.
Change-Id: I737cafebd836f3d8eb702beac557b4731f69c6f6
related-to-bug: 5196490
