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-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
