The audio input HAL normally runs on the same thread as RecordThread (it is
called by RecordThread),
so I think this is OK. But I will ask others to confirm.
On Tuesday, April 28, 2015 at 8:29:48 PM UTC-7, Hongyan wrote:
>
> I have a question about the preprocessing effects integration model in
>
> current audio framework, could anyone help on?
>
>
>
>
>
>
>
> Currently Android provided 3 kinds of preprocessing effects:
>
> AEC/NS/AGC and they’re wrapped into libaudiopreprocessing.so
>
>
>
> When App(Eg: Hangout) created such kind effects (type == what defined
>
> in libaudiopreprocessing.so), effects will be created and then handle
>
> will passed to HAL for further processing.
>
>
>
>
>
>
>
> SO maybe audio flinger should not call process_l function anymore for
>
> PRE or PROC effects, right? because they’re suppose to be handled in HAL.
>
>
>
>
>
>
>
> But in bool AudioFlinger::RecordThread::threadLoop()
>
>
>
>
>
>
>
> size_t size = effectChains.size();
>
>
>
> for (size_t i = 0; i < size; i++) {
>
>
>
> // thread mutex is not locked, but effect chain is locked
>
>
>
> effectChains[i]->process_l();
>
>
>
> }
>
>
>
>
>
>
>
> All of effects will be processed no matter if it’s PRE or PROC, so
>
> it’s possible both HAL and Audioflinger called the process function.
>
> It’s not expected. Is't a bug?
>
--
--
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/d/optout.
