[pulseaudio-discuss] pulseaudio-discuss Digest, Vol 46, Issue 50

[Arun Raghavan]

On 16 March 2015 at 10:48, Radhakrishnan, Manjula (M.)
<rmanjula at visteon.com> wrote:
[...]
>> 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.
>
> [rmanjula ] I have tried to explain the function in which the PA read is being blocked for a long time when PA write has started much earlier.

I see. Do you know what it is blocked on? Is data from the server
available and being sent?

>> 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.
>
> [rmanjula] The steps given below could reproduce the issue.
>
> If you're doing anything non-trivial, you probably want to use the async API, and not pa_simple_*(), btw.
>
> [rmanjula] The PA is used only for data routing between processes and no other functionality of PA is used. DATA from Process A to Process B through PA.
>
>> 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?
>
> [rmanjula]  yes , the same behavior is seen with parec as well .

And you see the same behaviour on the desktop as on your device?

The way the API is, you should not be seeing this issue. It would be
good to first see if the problem occurs on the desktop. If it does,
then we can try to investigate the exact setup and cause. If not, you
might have a problem specific to your platform.

Cheers,
Arun