Effects are applied to normal tracks only, not fast tracks. They are applied by normal mixer, prior to entering the fast mix. This lack of effects on fast tracks is another reason why fast mixer is "fast" relative to normal mixer (in addition to other reasons listed earlier).
On Wednesday, November 21, 2012 3:14:14 PM UTC-8, Previr Rangroo wrote: > > Hello Glenn, > > To continue the conversation forward on Track Effects being avoided by the > FastMixer, can the same be said of the Effects on SessionId 0 (the Global > Effects, if you will)? Will these global effects process the submix > (mFastTracks[0]) from the normal mixer thread only and then be mixed with > the FastMixer tracks *OR *is the combined output from FastMixer processed > by the Global Effects? > > If latter is the case, which seems to be my observation as well, doesn't > it defeat the purpose of having a dedicated fast lane for the Fast Tracks? > > Any comments will be highly appreciated. > > Best regards, > Previr > > On Wednesday, September 19, 2012 1:40:02 AM UTC+10, Glenn Kasten wrote: >> >> 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 <[email protected]> >>> >>>> 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 <[email protected]> >>>>> >>>>>> 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: [email protected] >>>> website: http://groups.google.com/group/android-porting >>>> >>> >>> -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
