Hi Glenn, Thanks for your response.
I understand your mean. I mean is if there is no any new states available from normal mixer, then FastMixer will get the old state again. If this old state command is MIX_WRITE, then at this time, FastMixer will write the mixBuffer again which stored the PCM data mixed at last time. Is it not a issue? if normal mixer have a long time latency which cause long time not send new state to FastMixer, then FastMixer will write the same data for many times. To my understanding, the DUT user will listen same sound for many millisecond, maybe like noise. I don't know my understanding if is correct, please help confirm it. Thanks Yu 2012/9/17 Glenn Kasten <gkas...@android.com> > No - if there is not a new state available from normal mixer, then > FastMixer will continue to operate correctly using the old state. State > includes many things, but most important is the set of active fast tracks. > The idle command is only used for major mode changes, not for state changes. > > > On Friday, September 14, 2012 2:21:08 AM UTC-7, big_fish_ wrote: > >> Hi glenn, >> >> Thanks for your reply. >> I have another question about FastMixer stat machine. >> To my understanding, the MIX_WRITE process as following: >> 1, get next FastMixerState from FastMixerStateQueue. >> 2, get its command >> 3, if command equal MIX_WRITE, then do mixer and write operations. >> >> After the step three done, FastMixer will continue to call poll to get >> new FastMixerState from FastMixerStateQueue. >> But if at this time, if MixerThread is busy on do mixer, resample and >> audio effect for other Tracks which cost a long latency. Then it will >> cause MixerThread haven't send any new FastMixerState to FastMixer, then >> FastMixer will get the old one again, and do above steps again. >> >> I think after the step 3, FastMixer should clear the >> handled FastMixerState.**mCommand to HOT_IDLE to avoid above issue. >> >> Please help check if my understanding if is correct. >> Thansk >> Yu >> >> >> 2012/9/7 Glenn Kasten <gka...@android.com> >> >>> 1. You didn't mention if you're developing Android apps or the platform. >>> If you're an Android app developer, you should be using only documented >>> public APIs. For audio output, that's Java language >>> android.media.AudioTrack in SDK and C language OpenSL ES AudioPlayer with >>> PCM buffer queue in NDK. The AUDIO_OUTPUT_FLAG_FAST is an internal >>> symbol that's used only at the AudioTrack C++ level, and that's not a >>> documented public API. So you should not need to deal with >>> AUDIO_OUTPUT_FLAG_FAST. >>> >>> But if you're doing platform development such as porting, it can be >>> helpful to understand the internal implementation in JB ... >>> AUDIO_OUTPUT_FLAG_FAST is a hint from the API level that this >>> application would like to use a lower latency, fewer feature, audio track >>> if one is available. The request is not guaranteed to be accepted by the >>> audio server (AudioFlinger). The fewer features that are not available >>> include effects, as you said, and also sample rate conversion. If >>> AudioFlinger can handle the request it will create a "fast track", >>> otherwise a normal track. >>> >>> 2. The "fast" in FastMixer means that it executes more often, and that >>> it uses less CPU time each time it runs, than the normal mixer thread. The >>> normal mixer thread runs about once every 20 ms, and the FastMixer thread >>> runs at rate of once per HAL buffer (which is ideally less than 20 ms). The >>> FastMixer thread supports up to 7 fast tracks, and does not support sample >>> rate conversion of effects. So it uses a limited amount of CPU each time it >>> runs. The normal mixer thread supports more tracks (up to 32), and supports >>> sample rate conversion and effects. So it can use more CPU each time it >>> runs. The main purpose of FastMixer design was not to take advantage of >>> multi-core. >>> >>> On Tuesday, September 4, 2012 6:59:27 PM UTC-7, big_fish_ wrote: >>>> >>>> I am a android developer, I just read the FastMixer code of Jellybean. >>>> >>>> I have some questions, >>>> >>>> 1, If submit AudioTrack with AUDIO_OUTPUT_FLAG_FAST flag, then this Track >>>> can't do AudioEffect handle, right? >>>> >>>> I noticed that FastMixer thread handle all FastTacks without >>>> AudioEffect. Except mFastTracks[0], because the zero FastTrack is >>>> passed from MixerThread which was already through mixer and effect handled. >>>> right? >>>> >>>> 2, About the performance, why FastMixer is faster then before? >>>> >>>> If we have 20 tracks, we set 8 tracks as FastMixer, and 12 as normal >>>> tracks, >>>> then there are two threads to do mixer. So if we run on dual core CPU, then >>>> we have multithreading adventage. >>>> >>>> But if we have 32 tracks are all as FastTrack, then MixerThread will not >>>> do mixer. then there will have no multithreading adventage. >>>> >>>> >>>> >>>> -- >>> unsubscribe: android-porti...@**googlegroups.com >>> website: >>> http://groups.google.com/**group/android-porting<http://groups.google.com/group/android-porting> >>> >> >> -- > unsubscribe: android-porting+unsubscr...@googlegroups.com > website: http://groups.google.com/group/android-porting > -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
