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
