821 lines
23 KiB
C++
Raw Normal View History

/*
**
** Copyright 2008, The Android Open Source Project
**
** Licensed under the Apache License, Version 2.0 (the "License");
** you may not use this file except in compliance with the License.
** You may obtain a copy of the License at
**
** http://www.apache.org/licenses/LICENSE-2.0
**
** Unless required by applicable law or agreed to in writing, software
** distributed under the License is distributed on an "AS IS" BASIS,
** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
** See the License for the specific language governing permissions and
** limitations under the License.
*/
//#define LOG_NDEBUG 0
#define LOG_TAG "AudioRecord"
#include <stdint.h>
#include <sys/types.h>
#include <sched.h>
#include <sys/resource.h>
#include <private/media/AudioTrackShared.h>
#include <media/AudioSystem.h>
#include <media/AudioRecord.h>
#include <media/mediarecorder.h>
#include <binder/IServiceManager.h>
#include <utils/Log.h>
#include <binder/Parcel.h>
#include <binder/IPCThreadState.h>
#include <utils/Timers.h>
#define LIKELY( exp ) (__builtin_expect( (exp) != 0, true ))
#define UNLIKELY( exp ) (__builtin_expect( (exp) != 0, false ))
namespace android {
// ---------------------------------------------------------------------------
// static
status_t AudioRecord::getMinFrameCount(
int* frameCount,
uint32_t sampleRate,
int format,
int channelCount)
{
size_t size = 0;
if (AudioSystem::getInputBufferSize(sampleRate, format, channelCount, &size)
!= NO_ERROR) {
LOGE("AudioSystem could not query the input buffer size.");
return NO_INIT;
}
if (size == 0) {
LOGE("Unsupported configuration: sampleRate %d, format %d, channelCount %d",
sampleRate, format, channelCount);
return BAD_VALUE;
}
// We double the size of input buffer for ping pong use of record buffer.
size <<= 1;
if (AudioSystem::isLinearPCM(format)) {
size /= channelCount * (format == AudioSystem::PCM_16_BIT ? 2 : 1);
}
*frameCount = size;
return NO_ERROR;
}
// ---------------------------------------------------------------------------
AudioRecord::AudioRecord()
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
: mStatus(NO_INIT), mSessionId(0)
{
}
AudioRecord::AudioRecord(
int inputSource,
uint32_t sampleRate,
int format,
uint32_t channels,
int frameCount,
uint32_t flags,
callback_t cbf,
void* user,
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
int notificationFrames,
int sessionId)
: mStatus(NO_INIT), mSessionId(0)
{
mStatus = set(inputSource, sampleRate, format, channels,
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
frameCount, flags, cbf, user, notificationFrames, sessionId);
}
AudioRecord::~AudioRecord()
{
if (mStatus == NO_ERROR) {
// Make sure that callback function exits in the case where
// it is looping on buffer empty condition in obtainBuffer().
// Otherwise the callback thread will never exit.
stop();
if (mClientRecordThread != 0) {
mClientRecordThread->requestExitAndWait();
mClientRecordThread.clear();
}
mAudioRecord.clear();
IPCThreadState::self()->flushCommands();
}
}
status_t AudioRecord::set(
int inputSource,
uint32_t sampleRate,
int format,
uint32_t channels,
int frameCount,
uint32_t flags,
callback_t cbf,
void* user,
int notificationFrames,
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
bool threadCanCallJava,
int sessionId)
{
LOGV("set(): sampleRate %d, channels %d, frameCount %d",sampleRate, channels, frameCount);
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
AutoMutex lock(mLock);
if (mAudioRecord != 0) {
return INVALID_OPERATION;
}
if (inputSource == AUDIO_SOURCE_DEFAULT) {
inputSource = AUDIO_SOURCE_MIC;
}
if (sampleRate == 0) {
sampleRate = DEFAULT_SAMPLE_RATE;
}
// these below should probably come from the audioFlinger too...
if (format == 0) {
format = AudioSystem::PCM_16_BIT;
}
// validate parameters
if (!AudioSystem::isValidFormat(format)) {
LOGE("Invalid format");
return BAD_VALUE;
}
if (!AudioSystem::isInputChannel(channels)) {
return BAD_VALUE;
}
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
int channelCount = AudioSystem::popCount(channels);
audio_io_handle_t input = AudioSystem::getInput(inputSource,
sampleRate, format, channels, (AudioSystem::audio_in_acoustics)flags);
if (input == 0) {
LOGE("Could not get audio input for record source %d", inputSource);
return BAD_VALUE;
}
// validate framecount
int minFrameCount = 0;
status_t status = getMinFrameCount(&minFrameCount, sampleRate, format, channelCount);
if (status != NO_ERROR) {
return status;
}
LOGV("AudioRecord::set() minFrameCount = %d", minFrameCount);
if (frameCount == 0) {
frameCount = minFrameCount;
} else if (frameCount < minFrameCount) {
return BAD_VALUE;
}
if (notificationFrames == 0) {
notificationFrames = frameCount/2;
}
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
mSessionId = sessionId;
// create the IAudioRecord
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
status = openRecord_l(sampleRate, format, channelCount,
frameCount, flags, input);
if (status != NO_ERROR) {
return status;
}
if (cbf != 0) {
mClientRecordThread = new ClientRecordThread(*this, threadCanCallJava);
if (mClientRecordThread == 0) {
return NO_INIT;
}
}
mStatus = NO_ERROR;
mFormat = format;
// Update buffer size in case it has been limited by AudioFlinger during track creation
mFrameCount = mCblk->frameCount;
mChannelCount = (uint8_t)channelCount;
mChannels = channels;
mActive = 0;
mCbf = cbf;
mNotificationFrames = notificationFrames;
mRemainingFrames = notificationFrames;
mUserData = user;
// TODO: add audio hardware input latency here
mLatency = (1000*mFrameCount) / sampleRate;
mMarkerPosition = 0;
mMarkerReached = false;
mNewPosition = 0;
mUpdatePeriod = 0;
mInputSource = (uint8_t)inputSource;
mFlags = flags;
mInput = input;
return NO_ERROR;
}
status_t AudioRecord::initCheck() const
{
return mStatus;
}
// -------------------------------------------------------------------------
uint32_t AudioRecord::latency() const
{
return mLatency;
}
int AudioRecord::format() const
{
return mFormat;
}
int AudioRecord::channelCount() const
{
return mChannelCount;
}
uint32_t AudioRecord::frameCount() const
{
return mFrameCount;
}
int AudioRecord::frameSize() const
{
if (AudioSystem::isLinearPCM(mFormat)) {
return channelCount()*((format() == AudioSystem::PCM_8_BIT) ? sizeof(uint8_t) : sizeof(int16_t));
} else {
return sizeof(uint8_t);
}
}
int AudioRecord::inputSource() const
{
return (int)mInputSource;
}
// -------------------------------------------------------------------------
status_t AudioRecord::start()
{
status_t ret = NO_ERROR;
sp<ClientRecordThread> t = mClientRecordThread;
LOGV("start");
if (t != 0) {
if (t->exitPending()) {
if (t->requestExitAndWait() == WOULD_BLOCK) {
LOGE("AudioRecord::start called from thread");
return WOULD_BLOCK;
}
}
t->mLock.lock();
}
AutoMutex lock(mLock);
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
// acquire a strong reference on the IAudioRecord and IMemory so that they cannot be destroyed
// while we are accessing the cblk
sp <IAudioRecord> audioRecord = mAudioRecord;
sp <IMemory> iMem = mCblkMemory;
audio_track_cblk_t* cblk = mCblk;
if (mActive == 0) {
mActive = 1;
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
cblk->lock.lock();
if (!(cblk->flags & CBLK_INVALID_MSK)) {
cblk->lock.unlock();
ret = mAudioRecord->start();
cblk->lock.lock();
if (ret == DEAD_OBJECT) {
cblk->flags |= CBLK_INVALID_MSK;
}
}
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
if (cblk->flags & CBLK_INVALID_MSK) {
ret = restoreRecord_l(cblk);
}
cblk->lock.unlock();
if (ret == NO_ERROR) {
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
mNewPosition = cblk->user + mUpdatePeriod;
cblk->bufferTimeoutMs = MAX_RUN_TIMEOUT_MS;
cblk->waitTimeMs = 0;
if (t != 0) {
t->run("ClientRecordThread", THREAD_PRIORITY_AUDIO_CLIENT);
} else {
setpriority(PRIO_PROCESS, 0, THREAD_PRIORITY_AUDIO_CLIENT);
}
} else {
mActive = 0;
}
}
if (t != 0) {
t->mLock.unlock();
}
return ret;
}
status_t AudioRecord::stop()
{
sp<ClientRecordThread> t = mClientRecordThread;
LOGV("stop");
if (t != 0) {
t->mLock.lock();
}
AutoMutex lock(mLock);
if (mActive == 1) {
mActive = 0;
mCblk->cv.signal();
mAudioRecord->stop();
// the record head position will reset to 0, so if a marker is set, we need
// to activate it again
mMarkerReached = false;
if (t != 0) {
t->requestExit();
} else {
setpriority(PRIO_PROCESS, 0, ANDROID_PRIORITY_NORMAL);
}
}
if (t != 0) {
t->mLock.unlock();
}
return NO_ERROR;
}
bool AudioRecord::stopped() const
{
return !mActive;
}
uint32_t AudioRecord::getSampleRate()
{
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
AutoMutex lock(mLock);
return mCblk->sampleRate;
}
status_t AudioRecord::setMarkerPosition(uint32_t marker)
{
if (mCbf == 0) return INVALID_OPERATION;
mMarkerPosition = marker;
mMarkerReached = false;
return NO_ERROR;
}
status_t AudioRecord::getMarkerPosition(uint32_t *marker)
{
if (marker == 0) return BAD_VALUE;
*marker = mMarkerPosition;
return NO_ERROR;
}
status_t AudioRecord::setPositionUpdatePeriod(uint32_t updatePeriod)
{
if (mCbf == 0) return INVALID_OPERATION;
uint32_t curPosition;
getPosition(&curPosition);
mNewPosition = curPosition + updatePeriod;
mUpdatePeriod = updatePeriod;
return NO_ERROR;
}
status_t AudioRecord::getPositionUpdatePeriod(uint32_t *updatePeriod)
{
if (updatePeriod == 0) return BAD_VALUE;
*updatePeriod = mUpdatePeriod;
return NO_ERROR;
}
status_t AudioRecord::getPosition(uint32_t *position)
{
if (position == 0) return BAD_VALUE;
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
AutoMutex lock(mLock);
*position = mCblk->user;
return NO_ERROR;
}
unsigned int AudioRecord::getInputFramesLost()
{
if (mActive)
return AudioSystem::getInputFramesLost(mInput);
else
return 0;
}
// -------------------------------------------------------------------------
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
// must be called with mLock held
status_t AudioRecord::openRecord_l(
uint32_t sampleRate,
int format,
int channelCount,
int frameCount,
uint32_t flags,
audio_io_handle_t input)
{
status_t status;
const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger();
if (audioFlinger == 0) {
return NO_INIT;
}
sp<IAudioRecord> record = audioFlinger->openRecord(getpid(), input,
sampleRate, format,
channelCount,
frameCount,
((uint16_t)flags) << 16,
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
&mSessionId,
&status);
if (record == 0) {
LOGE("AudioFlinger could not create record track, status: %d", status);
return status;
}
sp<IMemory> cblk = record->getCblk();
if (cblk == 0) {
LOGE("Could not get control block");
return NO_INIT;
}
mAudioRecord.clear();
mAudioRecord = record;
mCblkMemory.clear();
mCblkMemory = cblk;
mCblk = static_cast<audio_track_cblk_t*>(cblk->pointer());
mCblk->buffers = (char*)mCblk + sizeof(audio_track_cblk_t);
Fix issue 2553359: Pandora does not work well with Passion deskdock / Cardock. The problem is due to a too big difference between the buffer size used at the hardware interface and at the A2DP interface. When no resampling occurs we don't notice problems but the timing is very tight. As soon as resampling is activated, the AudioTrack underruns. This is because the AudioTrack buffers are not resized when moving the AudioTrack from hardware to A2DP output. The AudioTrack buffers are calculated based on a hardware output buffer size of 3072 bytes. Which is much less than the A2DP output buffer size (10240). The solution consists in creating new tracks with new buffers in AudioFlinger when the A2DP output is opened instead of just transfering active tracks from hardware output mixer thread to the new A2DP output mixer thread. To avoid synchronization issues between mixer threads and client processes, this is done by invalidating tracks by setting a flag in their control block and having AudioTrack release the handle on this track (IAudioTrack) and create a new IAudioTrack when this flag is detected next time obtainBuffer() or start() is executed. AudioFlinger modifications: - invalidate the tracks when setStreamOutput() is called - make sure that notifications of output opening/closing and change of stream type to output mapping are sent synchronously to client process. This is necessary so that AudioSystem has the new stream to output mapping when the AudioTrack detects the invalidate flag in the client process. Previously their were sent when the corresponding thread loop was executed. AudioTrack modifications: - move frame count calculation and verification from set() to createTrack() so that is is updated every time a new IAudioTrack is created. - detect track invalidate flag in obtainBuffer() and start() and create a new IAudioTrack. AudioTrackShared modifications - group all flags (out, flowControlFlag, forceReady...) into a single bit filed to save space. Change-Id: I9ac26b6192230627d35084e1449640caaf7d56ee
2010-05-14 03:26:45 -07:00
mCblk->flags &= ~CBLK_DIRECTION_MSK;
mCblk->bufferTimeoutMs = MAX_RUN_TIMEOUT_MS;
mCblk->waitTimeMs = 0;
return NO_ERROR;
}
status_t AudioRecord::obtainBuffer(Buffer* audioBuffer, int32_t waitCount)
{
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
AutoMutex lock(mLock);
int active;
status_t result;
audio_track_cblk_t* cblk = mCblk;
uint32_t framesReq = audioBuffer->frameCount;
uint32_t waitTimeMs = (waitCount < 0) ? cblk->bufferTimeoutMs : WAIT_PERIOD_MS;
audioBuffer->frameCount = 0;
audioBuffer->size = 0;
uint32_t framesReady = cblk->framesReady();
if (framesReady == 0) {
cblk->lock.lock();
goto start_loop_here;
while (framesReady == 0) {
active = mActive;
if (UNLIKELY(!active)) {
cblk->lock.unlock();
return NO_MORE_BUFFERS;
}
if (UNLIKELY(!waitCount)) {
cblk->lock.unlock();
return WOULD_BLOCK;
}
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
if (!(cblk->flags & CBLK_INVALID_MSK)) {
mLock.unlock();
result = cblk->cv.waitRelative(cblk->lock, milliseconds(waitTimeMs));
cblk->lock.unlock();
mLock.lock();
if (mActive == 0) {
return status_t(STOPPED);
}
cblk->lock.lock();
}
if (cblk->flags & CBLK_INVALID_MSK) {
goto create_new_record;
}
if (__builtin_expect(result!=NO_ERROR, false)) {
cblk->waitTimeMs += waitTimeMs;
if (cblk->waitTimeMs >= cblk->bufferTimeoutMs) {
LOGW( "obtainBuffer timed out (is the CPU pegged?) "
"user=%08x, server=%08x", cblk->user, cblk->server);
cblk->lock.unlock();
result = mAudioRecord->start();
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
cblk->lock.lock();
if (result == DEAD_OBJECT) {
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
cblk->flags |= CBLK_INVALID_MSK;
create_new_record:
result = AudioRecord::restoreRecord_l(cblk);
}
if (result != NO_ERROR) {
LOGW("obtainBuffer create Track error %d", result);
cblk->lock.unlock();
return result;
}
cblk->waitTimeMs = 0;
}
if (--waitCount == 0) {
cblk->lock.unlock();
return TIMED_OUT;
}
}
// read the server count again
start_loop_here:
framesReady = cblk->framesReady();
}
cblk->lock.unlock();
}
cblk->waitTimeMs = 0;
if (framesReq > framesReady) {
framesReq = framesReady;
}
uint32_t u = cblk->user;
uint32_t bufferEnd = cblk->userBase + cblk->frameCount;
if (u + framesReq > bufferEnd) {
framesReq = bufferEnd - u;
}
audioBuffer->flags = 0;
audioBuffer->channelCount= mChannelCount;
audioBuffer->format = mFormat;
audioBuffer->frameCount = framesReq;
audioBuffer->size = framesReq*cblk->frameSize;
audioBuffer->raw = (int8_t*)cblk->buffer(u);
active = mActive;
return active ? status_t(NO_ERROR) : status_t(STOPPED);
}
void AudioRecord::releaseBuffer(Buffer* audioBuffer)
{
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
AutoMutex lock(mLock);
mCblk->stepUser(audioBuffer->frameCount);
}
audio_io_handle_t AudioRecord::getInput()
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
{
AutoMutex lock(mLock);
return getInput_l();
}
// must be called with mLock held
audio_io_handle_t AudioRecord::getInput_l()
{
mInput = AudioSystem::getInput(mInputSource,
mCblk->sampleRate,
mFormat, mChannels,
(AudioSystem::audio_in_acoustics)mFlags);
return mInput;
}
Issue 2667801: [Audio Effect Framework] AudioFlinger, AudioMixer AudioTrack modifications. First drop of audio framework modifications for audio effects support. - AudioTrack/AudioRecord: Added support for auxiliary effects in AudioTrack Added support for audio sessions Fixed left right channel inversion in setVolume() - IAudioFlinger: Added interface methods for effect enumeraiton and instantiation Added support for audio sessions. - IAudioTrack: Added method to attach auxiliary effect. - AudioFlinger Created new classes to control effect engines in effect library and manage effect connections to tracks or output mix: EffectModule: wrapper object controlling the effect engine implementation in the effect library. There is one EffectModule per instance of an effect in a given audio session EffectChain: group of effects associated to one audio session. There is one EffectChain per audio session. EffectChain for session 0 is for output mix effects, other chains are attached to audio tracks with same session ID. Each chain contains a variable number of EffectModules EffectHandle: implements the IEffect interface. There is one EffectHandle object for each application controlling (or using) an effect module. THe EffectModule maintians a list of EffectHandles. Added support for effect modules and effect chains creation in PlaybackThread. modified mixer thread loop to allow track volume control by effect modules and call effect processing. -AudioMixer Each track now specifies its output buffer used by mixer for accumulation Modified mixer process functions to process tracks by groups of tracks with same buffer Modified track process functions to support accumulation to auxiliary channel Change-Id: I26d5f7c9e070a89bdd383e1a659f8b7ca150379c
2010-06-01 23:49:17 -07:00
int AudioRecord::getSessionId()
{
return mSessionId;
}
// -------------------------------------------------------------------------
ssize_t AudioRecord::read(void* buffer, size_t userSize)
{
ssize_t read = 0;
Buffer audioBuffer;
int8_t *dst = static_cast<int8_t*>(buffer);
if (ssize_t(userSize) < 0) {
// sanity-check. user is most-likely passing an error code.
LOGE("AudioRecord::read(buffer=%p, size=%u (%d)",
buffer, userSize, userSize);
return BAD_VALUE;
}
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
mLock.lock();
// acquire a strong reference on the IAudioRecord and IMemory so that they cannot be destroyed
// while we are accessing the cblk
sp <IAudioRecord> audioRecord = mAudioRecord;
sp <IMemory> iMem = mCblkMemory;
mLock.unlock();
do {
audioBuffer.frameCount = userSize/frameSize();
// By using a wait count corresponding to twice the timeout period in
// obtainBuffer() we give a chance to recover once for a read timeout
// (if media_server crashed for instance) before returning a length of
// 0 bytes read to the client
status_t err = obtainBuffer(&audioBuffer, ((2 * MAX_RUN_TIMEOUT_MS) / WAIT_PERIOD_MS));
if (err < 0) {
// out of buffers, return #bytes written
if (err == status_t(NO_MORE_BUFFERS))
break;
if (err == status_t(TIMED_OUT))
err = 0;
return ssize_t(err);
}
size_t bytesRead = audioBuffer.size;
memcpy(dst, audioBuffer.i8, bytesRead);
dst += bytesRead;
userSize -= bytesRead;
read += bytesRead;
releaseBuffer(&audioBuffer);
} while (userSize);
return read;
}
// -------------------------------------------------------------------------
bool AudioRecord::processAudioBuffer(const sp<ClientRecordThread>& thread)
{
Buffer audioBuffer;
uint32_t frames = mRemainingFrames;
size_t readSize;
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
mLock.lock();
// acquire a strong reference on the IAudioRecord and IMemory so that they cannot be destroyed
// while we are accessing the cblk
sp <IAudioRecord> audioRecord = mAudioRecord;
sp <IMemory> iMem = mCblkMemory;
audio_track_cblk_t* cblk = mCblk;
mLock.unlock();
// Manage marker callback
if (!mMarkerReached && (mMarkerPosition > 0)) {
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
if (cblk->user >= mMarkerPosition) {
mCbf(EVENT_MARKER, mUserData, (void *)&mMarkerPosition);
mMarkerReached = true;
}
}
// Manage new position callback
if (mUpdatePeriod > 0) {
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
while (cblk->user >= mNewPosition) {
mCbf(EVENT_NEW_POS, mUserData, (void *)&mNewPosition);
mNewPosition += mUpdatePeriod;
}
}
do {
audioBuffer.frameCount = frames;
// Calling obtainBuffer() with a wait count of 1
// limits wait time to WAIT_PERIOD_MS. This prevents from being
// stuck here not being able to handle timed events (position, markers).
status_t err = obtainBuffer(&audioBuffer, 1);
if (err < NO_ERROR) {
if (err != TIMED_OUT) {
LOGE_IF(err != status_t(NO_MORE_BUFFERS), "Error obtaining an audio buffer, giving up.");
return false;
}
break;
}
if (err == status_t(STOPPED)) return false;
size_t reqSize = audioBuffer.size;
mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer);
readSize = audioBuffer.size;
// Sanity check on returned size
if (ssize_t(readSize) <= 0) {
// The callback is done filling buffers
// Keep this thread going to handle timed events and
// still try to get more data in intervals of WAIT_PERIOD_MS
// but don't just loop and block the CPU, so wait
usleep(WAIT_PERIOD_MS*1000);
break;
}
if (readSize > reqSize) readSize = reqSize;
audioBuffer.size = readSize;
audioBuffer.frameCount = readSize/frameSize();
frames -= audioBuffer.frameCount;
releaseBuffer(&audioBuffer);
} while (frames);
// Manage overrun callback
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
if (mActive && (cblk->framesAvailable() == 0)) {
LOGV("Overrun user: %x, server: %x, flags %04x", cblk->user, cblk->server, cblk->flags);
AutoMutex _l(cblk->lock);
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
if ((cblk->flags & CBLK_UNDERRUN_MSK) == CBLK_UNDERRUN_OFF) {
cblk->flags |= CBLK_UNDERRUN_ON;
cblk->lock.unlock();
mCbf(EVENT_OVERRUN, mUserData, 0);
cblk->lock.lock();
}
}
if (frames == 0) {
mRemainingFrames = mNotificationFrames;
} else {
mRemainingFrames = frames;
}
return true;
}
Fix issue 3439872: video chat and bluetooth SCO 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
2011-03-07 14:52:59 -08:00
// must be called with mLock and cblk.lock held. Callers must also hold strong references on
// the IAudioRecord and IMemory in case they are recreated here.
// If the IAudioRecord is successfully restored, the cblk pointer is updated
status_t AudioRecord::restoreRecord_l(audio_track_cblk_t*& cblk)
{
status_t result;
if (!(cblk->flags & CBLK_RESTORING_MSK)) {
LOGW("dead IAudioRecord, creating a new one");
cblk->flags |= CBLK_RESTORING_ON;
// signal old cblk condition so that other threads waiting for available buffers stop
// waiting now
cblk->cv.broadcast();
cblk->lock.unlock();
// if the new IAudioRecord is created, openRecord_l() will modify the
// following member variables: mAudioRecord, mCblkMemory and mCblk.
// It will also delete the strong references on previous IAudioRecord and IMemory
result = openRecord_l(cblk->sampleRate, mFormat, mChannelCount,
mFrameCount, mFlags, getInput_l());
if (result == NO_ERROR) {
result = mAudioRecord->start();
}
if (result != NO_ERROR) {
mActive = false;
}
// signal old cblk condition for other threads waiting for restore completion
cblk->lock.lock();
cblk->flags |= CBLK_RESTORED_MSK;
cblk->cv.broadcast();
cblk->lock.unlock();
} else {
if (!(cblk->flags & CBLK_RESTORED_MSK)) {
LOGW("dead IAudioRecord, waiting for a new one to be created");
mLock.unlock();
result = cblk->cv.waitRelative(cblk->lock, milliseconds(RESTORE_TIMEOUT_MS));
cblk->lock.unlock();
mLock.lock();
} else {
LOGW("dead IAudioRecord, already restored");
result = NO_ERROR;
cblk->lock.unlock();
}
if (result != NO_ERROR || mActive == 0) {
result = status_t(STOPPED);
}
}
LOGV("restoreRecord_l() status %d mActive %d cblk %p, old cblk %p flags %08x old flags %08x",
result, mActive, mCblk, cblk, mCblk->flags, cblk->flags);
if (result == NO_ERROR) {
// from now on we switch to the newly created cblk
cblk = mCblk;
}
cblk->lock.lock();
LOGW_IF(result != NO_ERROR, "restoreRecord_l() error %d", result);
return result;
}
// =========================================================================
AudioRecord::ClientRecordThread::ClientRecordThread(AudioRecord& receiver, bool bCanCallJava)
: Thread(bCanCallJava), mReceiver(receiver)
{
}
bool AudioRecord::ClientRecordThread::threadLoop()
{
return mReceiver.processAudioBuffer(this);
}
// -------------------------------------------------------------------------
}; // namespace android