We could remove all effects in closeInput() but have to be careful with
race conditions.
This is the only way to also address the case of pre processing controlled
by apps and not released before the AudioRecord is closed.
But again I don't think this is a critical problem as any HAL design should
take care of resource allocation and release for all possible code paths.
On Tuesday, January 14, 2014 5:16:09 PM UTC-8, Uday Gupta wrote:
>
> Hi Eric,
>
> We can take care of it in Audio HAL but logically speaking since audio
> flinger calls add_audio_effect, it should also call remove_audio_effect.
> Tried below change to call setPreProcessorEnabled before release_input and
> seems to work but don't know if it is right thing to do. Now I see
> remove_audio_effect being called twice.
>
> void AudioPolicyService::releaseInput(audio_io_handle_t input)
> {
> if (mpAudioPolicy == NULL) {
> return;
> }
> Mutex::Autolock _l(mLock);
> ssize_t index = mInputs.indexOfKey(input);
> if (index >= 0) {
> InputDesc *inputDesc = mInputs.valueAt(index);
> setPreProcessorEnabled(inputDesc, false);
> delete inputDesc;
> }
>
> mpAudioPolicy->release_input(mpAudioPolicy, input);
>
> mInputs.removeItemsAt(index);
> }
>
> On Tuesday, January 14, 2014 1:51:52 PM UTC-8, Eric Laurent wrote:
>>
>> It is possible that remove_audio_effect is not called but as it is
>> because the input stream has already been closed it should not be a
>> problem. The HAL implementation should clean up its effect configuration if
>> needed when the input stream is closed.
>>
>>
>> On Tuesday, January 14, 2014 8:20:15 AM UTC-8, Uday Gupta wrote:
>>>
>>> Hi,
>>>
>>> Was able to figure out how the add_audio_effect is called. Was not
>>> loading the correct audio_effects.conf because of which the logs I had
>>> added were not showing up.
>>>
>>> Now I have another problem. remove_audio_effects is not getting called.
>>>
>>> AudioPolicyService::releaseInput->AudioPolicyManagerBase::releaseInput->mpClientInterface->closeInput->AudioFlinger::closeInput->closeInput_nonvirtual->AudioFlinger::RecordThread::clearInput(This
>>>
>>> will set mInput to NULL)
>>> Then
>>> AudioPolicyService::releaseInput->setPreProcessorEnabled
>>>
>>> Now when with either AudioFlinger::EffectModule::stop_l
>>> or AudioFlinger::EffectModule::~EffectModule() is called audio_stream_t
>>> *stream = thread->stream(); returns NULL as mInput is already set to NULL
>>> earlier and therefore remove_audio_effect doesn't get called.
>>>
>>> Is that a bug or I am looking at it wrong.
>>>
>>> Thanks
>>>
>>> On Monday, January 13, 2014 11:35:15 AM UTC-8, Uday Gupta wrote:
>>>>
>>>> Hi,
>>>>
>>>> I understand that platform developers can add their own pre processing
>>>> effects in audio_effects.conf.
>>>>
>>>> If the conditions match, then in audio policy service getInput
>>>> function, new AudioEffect will be created.
>>>>
>>>> My question is how does this effect start. Basically, how does
>>>> add_audio_effect get called to the HAL?
>>>>
>>>> Thanks
>>>>
>>>>
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-porting+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
