Audio effect framework is extended to suport effects on
output and input audio path.
AudioFlinger: Support for audio effects and effect chains is
moved from PlaybackThread class to ThreadBase class so that
RecordThread can manage effects.
Effects of type pre processing are allowed on record thread
only. When a pre processing is enabled, the effect interface handle is
passed down to the input stream so that the audio HAL can call the
process function. The record thread loop calls the effect chain process
function that will only manage the effect state and commands and skip the
process function.
AudioRecord: The audio session is allocated before calling getInput() into
audio policy serice so that the session is known before the input theead is
created and pre processings can be created on the correct session.
AudioPolicyService: default pre processing for a given input source are
loaded from audio_effects.conf file.
When an input is created, corresponding effects are created and enabled.
Change-Id: Id17119e0979b4dcf189b5c7957fec30dc3478790
This change makes MediaPlayer connect to the ANativeWindow to which it
is going to render video frames and disconnect when it is done.
Change-Id: I88ab5c2fe62493aabdc84a283ff31634f795d415
Moved specific effect header files to
system/media/audio_effects/include/audio_effects
and renamed to lower case (effect_xxx.h).
Change-Id: Icfc2264bfd013cab0395d7e310ada636b9fe3621
The purpose of ICameraRecordingProxy and ICameraRecordingProxyListener is to
allow applications using the camera during recording.
Camera service allows only one client at a time. Since camcorder application
needs to own the camera to do things like zoom, the media recorder cannot
access the camera directly during recording. So ICameraRecordingProxy is a proxy
of ICamera, which allows the media recorder to start/stop the recording and
release recording frames. ICameraRecordingProxyListener is an interface that
allows the recorder to receive video frames during recording.
ICameraRecordingProxy
startRecording()
stopRecording()
releaseRecordingFrame()
ICameraRecordingProxyListener
dataCallbackTimestamp()
The camcorder app opens the camera and starts the preview. The app passes
ICamera and ICameraRecordingProxy to the media recorder by
MediaRecorder::setCamera(). The recorder uses ICamera to setup the camera in
MediaRecorder::start(). After setup, the recorder disconnects from camera
service. The recorder calls ICameraRecordingProxy::startRecording() and
passes a ICameraRecordingProxyListener to the app. The app connects back to
camera service and starts the recording. The app owns the camera and can do
things like zoom. The media recorder receives the video frames from the
listener and releases them by ICameraRecordingProxy::releaseRecordingFrame.
The recorder calls ICameraRecordingProxy::stopRecording() to stop the
recording.
The call sequences are as follows:
1. The app: Camera.unlock().
2. The app: MediaRecorder.setCamera().
3. Start recording
(1) The app: MediaRecorder.start().
(2) The recorder: ICamera.unlock() and ICamera.disconnect().
(3) The recorder: ICameraRecordingProxy.startRecording().
(4) The app: ICamera.reconnect().
(5) The app: ICamera.startRecording().
4. During recording
(1) The recorder: receive frames from ICameraRecordingProxyListener.dataCallbackTimestamp()
(2) The recorder: release frames by ICameraRecordingProxy.releaseRecordingFrame().
5. Stop recording
(1) The app: MediaRecorder.stop()
(2) The recorder: ICameraRecordingProxy.stopRecording().
(3) The app: ICamera.stopRecording().
bug:2644213
Change-Id: I15269397defc25cbbcae16abc071c8349c123122
Record and playback objects (resp AudioRecord and AudioTrack)
are created using a channel mask, but this information is lost
in the mixer because only the channel count is known to
AudioFlinger. A channel count can always be derived from a
channel mask.
The change consists in:
- disambiguiting variable names for channel masks and counts
- passing the mask information from the client to AudioFlinger
and the mixer.
- when using the DIRECT ouput, only verifying the format of
the track is compatible with the output's for PCM.
Change-Id: I50d87bfb7d7afcabdf5f12d4ab75ef3a54132c0e
o This start time offset is used in the media framework to eliminate
the recording sound in the recorded file.
Change-Id: I97926a74f0743b8a4f985d51334e8d1486a318ea
related-to-bug: 4390777
Don't let the "no media" status of one directory leak to the remaining files
and directories in the same parent.
Bug: 4364077
Change-Id: Ie756ccd06b1962b06143fc02a1a3927c3aba143a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Previously we ignored any files and directories that had name started with '.'
and ignored any directories that contained a ".nomedia" file.
Now to support transferring any file via MTP, we now add these previously ignored files
to the media database, but will not mark them as audio, video, image or playlist files.
That way they will be included in the files table but will be hidden from the
audio, video, images and playlist views that are used by apps like Music and Gallery.
Bug: 3405327
Change-Id: Ibb37bb2856a0684ce9f685ed565ad35347622834
Signed-off-by: Mike Lockwood <lockwood@android.com>
Don't let the "no media" status of one directory leak to the remaining files
and directories in the same parent.
Bug: 4364077
Change-Id: I30943222dc292818cff00ee8169be7a695eed174
Signed-off-by: Mike Lockwood <lockwood@android.com>
Previously we ignored any files and directories that had name started with '.'
and ignored any directories that contained a ".nomedia" file.
Now to support transferring any file via MTP, we now add these previously ignored files
to the media database, but will not mark them as audio, video, image or playlist files.
That way they will be included in the files table but will be hidden from the
audio, video, images and playlist views that are used by apps like Music and Gallery.
Bug: 3405327
Change-Id: I2d7285bd32e06c1a5c4ef6a8a15f8f8b2c33b39b
Signed-off-by: Mike Lockwood <lockwood@android.com>
through listener during video playback.
- Add OnTimedTextListener in the MediaPlayer
For feature request 800939.
Change-Id: I65072c27acb4c0037109a72be38c73e9f667420f
Current implementation of AudioEffect class destructor disables
the effect before disconnecting from IAudioEffect interface.
This is problematic when more than one client has a handle on the same
effect engine as destroying one handle will disable the effect which is
not the intended behavior.
Change-Id: I10eacf981506469a7ef4eb9a1650813f0848de5d
The first fix (commit 913af0b4) is problematic because it makes threads
in mediaserver process block on the cblk mutex. This is not permitted
as it can cause audio to skip or worse have a malicious application
prevent all audio playback by keeping the mutex locked.
The fix consists in using atomic operations when modifying the control
block flags.
Also fixed audio_track_cblk_t::framesReady() so that it doesn't block
when called from AudioFlinger (only applies when a loop is active).
Change-Id: Ibf0abb562ced3e9f64118afdd5036854bb959428
this is the first step in unifying surfacetexture and surface.
for this reason the header files were not moved, as most of them
will eventually go away.
NOTE: currently we keep libsurfaceflinger_client.so as an empty
library to workaround prebuilt binaries wrongly linking against
it.
Change-Id: I130f0de2428e8579033dc41394d093f4e1431a00
The problem is that when switching from A2DP to device speakers or headset,
The AudioTrack binder interface to AudioFlinger must be destroyed and restored
to accomodate new buffer size requirements. Current AudioTrack implementation
did not restore properly the PCM buffer write index which caused a mismatch between
the written frame count in the mediaplayer renderer and the AudioTrack. The renderer
could then believe the AudioTrack buffer was full and stop writing data preventing the
AudioTrack to reach a bufffer full condition and resume playback.
The rendered was also modified to refresh the AudioTrack frame count (buffer size)
inside the write loop in NuPlayer::Renderer::onDrainAudioQueue() as this count can change
from one write to the next.
Also modified AudioTrack::obtainBuffer() to check for track invalidated status before
querying for available space in the buffer. This avoids writing to the old track's
buffer until full before detecting the invalidated condition and create a new track.
Change-Id: I16a857e464e466880847f52f640820aa271539ad
Make sure that all read/modify/write operations on the AudioTrack
and AudioRecord control block flags field are protected by the
control block's mutex.
Also fix potential infinite loop in AudioTrack::write() if the
written size is not a multiple of frame size.
Change-Id: Ib3d557eb45dcc3abeb32c9aa56058e2873afee27
This change fixes the stability problems experienced when using
a bluetooth headset supporting both A2DP and SCO. Problems occur
when starting the video chat at which time the A2DP output is being
stopped to start SCO. At that time, active AudioTracks are invalidated
by AudioFlinger so that a new AudioTrack binder interface can be
recreated by the client process on the new mixer thread with correct parameters.
The problem was that the process to restore the binder interface was not
protected against concurrent requests which caused 2 binder interfaces
to be created sometimes. This could lead to permanent client deadlock
if one of the client threads was waiting for a condition of the first
created binder interface while the second one was created (as the AudioFlinger
would only signal conditions on the last one created).
This concurrent request situation is more likely to happen when a client
uses the JAVA AudioTrack as the JNI implementation uses simultaneously the
native AudioTrack callback and write push mechanisms. By doing so, the code
that checks if the binder interface should be restored (in obtainBuffer()) is
much more likely to be called concurrently from two different threads.
The fix consists in protecting the critical binder interface restore phase
with a flag in the AudioTrack control block. The first thread acting upon the binder
interface restore request will raise the flag and the second thread will just wait for
a condition to be signaled when the restore process is complete.
Also protected all accesses to the AudioTrack control block by a mutex to prevent
access while the track is being destroyed and restored. If a mutex cannot be held
(e.g because we call a callback function), acquire a strong reference on the IAudioTrack
to prevent its destruction while the cblk is being accessed.
Modified AudioTrack JNI to use GetByteArrayElements() instead of
GetPrimitiveArrayCritical() when writing audio buffers. Entering a critical section would
cause the JNI to abort if a mediaserver crash occurs during a write due to the AudioSystem
callback being called during the critical section when media server process restarts.
Anyway with current JNI implementation, either versions do not copy data most of the times
and the criticial version does not guaranty no data copy.
The same modifications have been made to AudioRecord.
Change-Id: Idc5aa711a04c3eee180cdd03f44fe17f3c4dcb52
