It's currently hard-coded to use kUseFastMixer = FastMixer_Static. I briefly tried the other options while developing it, but have not used them recently. So I'm not sure how well the other choices would work.
On Friday, August 9, 2013 11:20:37 PM UTC-7, 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.
