Every time a mixer thread runs through it's main loop, it gets the PCM data for each track input by a buffer provider. The buffer provider normally returns new PCM data each time it is called, or if there is not enough new data available then it returns a short (insufficient) count and that track will underrun. You can see this by adding some logs to the thread loops.
On Sunday, September 16, 2012 8:52:36 PM UTC-7, big_fish_ wrote: > > 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 <gka...@android.com <javascript:>> > >> 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-porti...@googlegroups.com <javascript:> >> website: http://groups.google.com/group/android-porting >> > > -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
