question about audio latency

123 views
Skip to first unread message

weiwei Zhang

unread,
May 11, 2015, 8:11:53 AM5/11/15
to android...@googlegroups.com

I am an android platform developer, recently I am doing some investigation about audio latency,and i have two question about it , could you help me on that?

1st question:

I just read the FastMixer code of LP5.0, when play a sound pool stream, a fast track such as fast track1 will be created and audio flinger will also write zero data to fast track0 , finally both of them will be mixed in fast mixer thread.

My question is why we need audio flinger audio_Out thread write zero data to fast track0 and then mixed with fast track1,as i known, it will add more latency for sound pool playback. Whether we can mix fast track 1-7 directly by fast mixer thread and write them to HAL?

 2nd question is:

The definition of warm latency in CDD is:

"warm output latency" is defined to be the interval between when an application requests audio playback and when sound begins playing, when the audio system has been recently used but is currently idle (that is, silent).

As I known, when the audio system has been recently used but is currently idle, audio_out thread in audio flinger will write zero data to SRAM(at most 3 seconds), when application requests audio playback, should the warm latency include the delay caused by SRAM zero data? 


Thank you firstly.

Glenn Kasten

unread,
May 11, 2015, 8:48:57 AM5/11/15
to android...@googlegroups.com, horiz...@163.com
Question 1:

The pipe from normal mixer's submix to fast mixer track 0 is needed for devices that can only handle a single output stream in the kernel.
This was a problem initially.  Nowadays, more devices support mixing in the kernel, so we could remove the pipe.
I am filing an internal issue to track this.  Please feel free to file an external issue here also, if you want to:

You are correct that mixing track 0 from the submix does add computational delay, but it does not add algorithmic delay
or significant latency.  So removing or disabling the pipe when possible should be more efficient for CPU usage / power consumption,
but I don't expect it will decrease latency significantly.

Question 2:

I am not sure what you mean, by delay caused by SRAM zero data.  Do you mean the computational delay
caused by writing zeroes into SRAM?  If so, that is not a significant contributor to total latency.
Or do you mean something else?

weiwei Zhang

unread,
May 12, 2015, 4:09:38 AM5/12/15
to android...@googlegroups.com, horiz...@163.com
Hi, Glenn Kasten
Thank you for your quickly response.
For question 1:
We have two output threads in audio flinger, one is for deep buffer (music playback), the other is for low latency(). And low latency output thread will enable fast mixer staticly,this thread will mix normal tracks and write them to fast track0's monopipe.
Although monopipe will not  add algorithmic delay or significant latency for cold output latency, but it will add significant latency for continuous output latency for normal track playback, because  the fast track0 has a big buffer(4*normalFramecount) for audio raw data.
Continuous output latency will compute all of buffer.
Besides, for fast tracks playback,such as sound pool stream playback, is the fast track0's zero data necessary?

For question 2:
when we test warm output latency, we playback a normal track for a while and the sleep it for 1 second to let audio system in idle state. At the moment , audio_out thread will write 1 second zero data to SRAM, that is to say SRAM is filled will zero data. If we restart the normal track, kernel will consume SRAM zero data firstly(in our chip design,this SRAM latency will be 1024 frames/44.100=23ms), device will be silent for 23ms. And then kernel will consume real normal track data which audio_out thread write.
My question is when application requests restart audio playback, should the warm output latency include the delay(in our desigh , 23ms) caused by SRAM zero data? 

Thank you.

在 2015年5月11日星期一 UTC+8下午8:48:57,Glenn Kasten写道:
Reply all
Reply to author
Forward
0 new messages