[pulseaudio-discuss] PA- Performance issue with PA read and CPU consumption in idle state

[Arun Raghavan]

On 12 February 2015 at 19:33, Radhakrishnan, Manjula (M.)
<rmanjula at visteon.com> wrote:
> Hi ,
>
> Thanks for the reply.
>
> The platform is based on ARM Cortex A9 core.
>
> Regarding the Issue 1  reported :
>
> On analyzing the pa_simple_read , the following observations are seen.
>
> The delay is casued by pa_stream_peek not retuned read length , not clear on
> why this could fail since pa write has started.

Not sure what you mean here.

> In pa_stream_peek , read length is returned as null , hence blocked at
> "pa_threaded_mainloop_wait".
> It comes out of " pa_threaded_mainloop_wait" , and again fails at
> pa_stream_peek.
> This looping happens between 5- 8 times then it returns successfully from
> pa_simple_read.

It's pretty hard for me to say much about this without some sort of
test case that I can reproduce here.

If you're doing anything non-trivial, you probably want to use the
async API, and not pa_simple_*(), btw.

> We ran another test code to eliminate the influence of CPU or other
> application ,   The test script is as follows :
>
> 1.  paplay -droute_test /home/test441.wav          /*  route_test is a null
> sink , play audio to this null sink  */
> 2. sleep 1            /* sleep for 1 sec before read */
> 3. ./test_code.sh    /*  test code to read data from the null sink  , added
> time stamp to measure the duration inside pa_simpe_read */
>
> With the above script ,  the measured time inside first pa_simpe_read is 1.8
> sec
>
> The issue is not seen if paplay is immediately followed by PA read , i.e
>
> 1.  paplay -droute_test /home/test441.wav      /* route_test is a null sink
> */
> 2. ./test_code.sh    /*  test code to read data from the null sink  , added
> time stamp to measure the duration inside pa_simpe_read */
>
> With this test , the measured time inside pa_simpe_read is few micro seconds
> and  there is no block inside pa_simpe_read.
>
> when the test script was executed , no other major CPU consumption in the
> core.
>
> We are trying to understand the impact of starting the pa write earlier than
> pa read and the cause of this delay.
>
> The pa write instance is in an external application and operates
> independently and the instance cannot be synchronised with pa read start.

Does this happen with parec as well? And if yes, is the behaviour on
your desktop the same as on your device?

> 2.  On Issue 2 ,
>
> The input and output both are at 44.1 Khz and no resampling of audio
> involved.  CPU is seen when there is no write/read hapenning.
>
> Is there any specific PA compile time options to be set for optimized CPU ?
> please let know .

In most cases, it'll all be automatically detected based on your
-march flags, and what's available at run-time.

Cheers,
Arun