Dear Mr.Kasten, Thank you very much. I will contact official directly. I will reply you if they have a official comment on this question.
Thanks. 2013/4/17 Glenn Kasten <gkas...@android.com> > My unofficial opinion is that starting measurement at line #246 might give > you the cold latency, > and help you to measure the warmup time for audio pipeline to be powered > up etc. > > And that starting measurement at line 95 might give you the continuous > latency > after audio pipeline is already running. > > For official contacts about compatibility, see > http://source.android.com/compatibility/contact-us.html > > > On Sunday, April 14, 2013 7:31:21 PM UTC-7, Ship Hsu wrote: > >> Dear Mr.Kasten, >> Sorry for TYPO on actually I want to say is *#246* not #264. >> Summarize the difference of these, I make a diagram for explain it. >> Just like digram, FastMixer don't know a new fasttrack added until >> PlaybackMixer notify it. >> >> #246( *write to fasttrack and active it*) and #95(* Write to fasttrack >> which is already active*) are two different path. >> >> The mainly different is #246 will pass PlaybackMixer threadloop which >> will increase latency. >> We have a hardware system for measure the latency between testpoint and >> physical sound output. >> How do you thinks about the possible test point (#246, or #95) ? >> >> >> [image: 內置圖片 1] >> >> >> Thanks a lot. >> >> P.S. Could you give me the official contact information if you knew it. >> Thanks again. >> >> Sincerely, >> >> >> 2013/4/13 Glenn Kasten <gka...@android.com> >> >>> First, regarding your specific question: >>> >>> Line 95 has: >>> res = (*queueItf)->Enqueue(... >>> which make sense to me that it could be a *possible* test point. >>> >>> But line 264 has: >>> /* Make sure player is stopped */ >>> res = (*playItf)->SetPlayState(**playItf, SL_PLAYSTATE_STOPPED); >>> That doesn't seem to make sense, are you sure you meant that line number? >>> >>> ---- >>> >>> Second, for the larger question of how to test, >>> unfortunately I'm not permitted to give opinions on this issue >>> as it's outside of my scope [I work on the audio platform, not on >>> conformance]. >>> My unofficial "guess" is that the time starting at Enqueue would make >>> sense as a starting measuring point for the continuous latency. >>> But you'll really need to check in with >>> your partner conformance contact to get an official answer. >>> >>> >>> On Thursday, April 11, 2013 11:16:24 PM UTC-7, Ship Hsu wrote: >>>> >>>> Dear Glenn Kasten, >>>> We are concern audio low latency of Android 4.2 Compatibility >>>> Definition of (android-4.2-cdd), which make a requirement: >>>> * 1. cold output latency of 100 milliseconds or less* >>>> * 2. continuous output latency of 45 milliseconds or less* >>>> In the document, *"If a device implementation meets the requirements >>>> of this section after any initial calibration when using the* >>>> *OpenSL ES PCM buffer queue API"*, we have a question of this >>>> definition, what is the state of opensles Audioplayer when we start the >>>> stopwatch? If there is a background sound playing, we should start the >>>> stopwatch from *"enable an audioplayer"* or from *"enqueue buffer in >>>> callback function".* >>>> >>>> As attachment (google opensles example), we should start audio latency >>>> measurement from line #264, or from line #95? >>>> >>>> Thank you! >>>> >>>> Sincerely, >>>> >>>> Glenn Kasten於 2012年9月7日星期五UTC+**8下午11時44分29秒寫道**： >>>>> >>>>> 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> >>> >>> --- >>> 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 android-porti...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > -- > unsubscribe: android-porting+unsubscr...@googlegroups.com > 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 android-porting+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- unsubscribe: android-porting+unsubscr...@googlegroups.com 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 android-porting+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
