Sure. Thanks for the help.
On Wednesday, January 15, 2014 9:10:08 AM UTC-8, Eric Laurent wrote:
>
> 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.
