audio/ogg has been the official mimetype for ogg vorbis audio for
a while now, so we should support it.
b/5824157
Change-Id: Ica86bdb3099a10785f1da9c3413284f3e11dc27e
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
Added the infrastructure to support the synchronization of playback and
capture actions on specific events.
The first requirement for this feature is to synchronize the audio capture
start with the full rendering of a given audio content.
The applications can further be extended to other use cases
(synchronized playback start...) by adding new synchronization events and
new synchronous control methods on player or recorders.
Also added a method to query the audio session from a ToneGenerator.
Change-Id: I4e47f5108c7cbbd3bd334a7fad9b3b6c5ba55d88
This is part of the multi-project commit to move the filter-framework
from system/media/mca to frameworks/base/media/mca.
Note that the filter-framework will soon be replaced with a refactored
version currently under API review (also to go under frameworks/base).
This move is done now to unblock the PDK efforts.
Change-Id: I9f42be5a12a9e8157512be11f04e38e4548970be
MediaScanner sets DATE_TAKEN with EXIF's datetime tag value. When this information is not available,
ExifInterface will simply return -1 which is accidentally used by MediaScanner.
Adding a check to avoid it so MediaProvider can calculate the date taken from last modified time instead.
Change-Id: I305b93a6c5602cbb9f97c3bbd384d358bda030c6
Current method implemented by the visualizer to detect that audioflinger has
stopped providing audio buffers does not work if the application
reads pcm captures too fast.
The fix consist in implementing a method based on real time measurement only.
One drawback is that the new method makes use of system calls that add some
overhead to the process and capture functions.
Change-Id: I53bd596b856f1cc7f0f47e08413af3335227100b
Reorganize SoundPool and JetPlayer code to be ready for the
creation of libmedia_native.
Split SoundPool between libsoundpool (JNI) and libmedia(sound pool implementation).
Remove dependencies on nativehelper/jni.h from JetPlayer.
Change-Id: I130c6014173b714329929dd82c5dfb70b757a610
o this is to resolve undesirable dependency of /frameworks/av/libvideoeditor on /frameworks/base/media/jni
o related-to-bug: 6214141
Change-Id: I62d08a7789ecb34d35cd22d2e6f68c3510c9bd90
The recent removal of the cache from MediaScanner (commit 58ef68905d67e356eb)
slowed down processing of playlists, in some cases significantly, due to every
line in a playlist prompting a query that looped over the entire audio table.
With this change, the query is only done once instead of for every line,
and the code starts iterating over the Cursor starting near the point of
the last match, instead of from the start. The latter is especially helpful
when the entire query result is too large to fit in a CursorWindow, since
it reduces the number of times that sqlite has to perform an offset query
under the hood to refil the window.
Change-Id: I9fea990b3b8c86571384de2122708fb7e809c355
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