Dear Glenn,
I understand that fast mixer dynamic policy is still under development,
and we will still use static policy at current stage.
My question is how will you deal with the scenario I mentioned during
dynamic policy development (in the future)? To reduce latency, we will use
small buffers for primary output, but if fast mixer is disabled since
there's no fast tracks, then the cycle time variance can not be guaranteed
and under-run may happen. Do you have any plan or method to resolve this
issue? Thanks.
On Saturday, August 10, 2013 2:20:37 PM UTC+8, Xin Qian wrote:
>
> We plan to use the following design:
> 1) Create 1 deep buffer output dedicated for music stream. (maybe 25ms x 8)
> 2) Create 1 low latency output for other streams. (maybe 3ms x 3)
> 3) Use fast mixer dynamic policy. So when there're fast tracks, enable
> fast mixer. If there's no fast track, disable fast mixer and use low
> latency output directly.
> Let's take VoIP as an example. VoIP uses VOICE_CALL stream, so it will go
> through low latency output, but NOT use fast mixer. In this case, mixer
> thread is not RT thread, so it can not guarantee the cycle time variance
> and may cause under-run. How did you handle such kind of issues? Maybe we
> could only use static policy? 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.
