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 <[email protected] <javascript:>> > >> 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: [email protected] <javascript:> >> 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] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- 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.
