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
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
This fixes a case where the RCD would display transport control
for a RemoteControlClient that didn't have audio focus.
This was happening because registering an RCD was directly calling
the updateRemoteControlDisplay method, without first calling
the checkUpdateRemoteControlDisplay method which verifies the
conditions before updating the display. One of those conditions
is that the audio focus stack shouldn't be empty.
To verify this fix, several functions were also rename to clearly
indicate the lock order and verify we properly synchronize on
the right objects. In doing so, a missing synchronization on
audio focus was found.
Change-Id: If1baaac224ea676aeb83ac0aefcc53f87461c32e
this change intends to support its very limited case and signals an error in
all other cases of unexpected PID changes that we cannot recover from.
Change-Id: Icbfdf9fe7461969e2a8781ed416f54d891dd789a
those that have a queue. This ensures that the player doesn't observe discontinuities
that don't match up across streams.
Also, make sure output buffers arriving from the decoder to be rendered are sent
back to the decoder if we started flushing.
Finally, don't parse TS packets for streams we don't support. And don't allocate
memory for them.
Change-Id: I708e0de4cba8110a62e4c8ceb1e5702430d5d2bb
A precondition for updateRemoteControlDisplay_syncRcs() is that
mRCStack is not null. This condition was not verified when
registering a RemoteControlDisplay.
Change-Id: I0b152410e57c590114b387e9ab83f0c4d15d060d
