This is starting a new topic on an old thread. Can you please start a new thread with new subject line to match? Thanks!
On Monday, June 24, 2013 4:46:27 AM UTC-7, Iroid wrote: > > Hi, > I am developing an audio conferencing application with 5 way > conference that will be part of Android firmware,. > Could you please let me know what is the best way to leverage Android > audio framework for this. > as of now I am considering this doing on AudioTrack level only. but have > feeling that this is not the best way. > > > > appreciate your help. > Thanks > > > On Friday, September 7, 2012 9:14:29 PM UTC+5:30, Glenn Kasten wrote: >> >> 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: [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
