Re: [android-porting] Re: Questions of fastmixer

[yu wang]

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

[yu wang]

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.

[Glenn Kasten]

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秒寫道：

[Ship Hsu]

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) ?

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>

--

--
unsubscribe: android-porti...@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-porti...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Glenn Kasten]

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

[Ship Hsu]

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 <gka...@android.com>

[Iroid]

Hi,

       I am developing an audio conferencing application with 5 way conference that will be part of Android firmware,.

 Could you please let me know what is the best way to leverage Android audio framework for this.

as of now I am considering this doing on AudioTrack level only. but have feeling that this is not the best way.

appreciate your help.

Thanks

[Glenn Kasten]

This is starting a new topic on an old thread.  Can you please start a new thread with new subject line to match? Thanks!