Hi Glenn, all What about effects on Session 0? Do these get applied to the output of the Fast mixer (which is the mix of fast tracks + the normal mixer)? If so, it seems to contradict the idea that it is a fast mixer, because Session 0 effects are still applying.
Can anyone suggest a code change which would make Session 0 effects only apply to the output of the "normal" mixer (before it is mixed into the fast mixer)? Kind regards Eugene On Friday, November 23, 2012 7:52:20 AM UTC+11, Glenn Kasten wrote: > > 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 <gka...@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-porti...@googlegroups.com >>>>> website: http://groups.google.com/group/android-porting >>>>> >>>> >>>> -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
