Hi, I have added my explanation below , is this a known limitation that writes to PA should occur only after read has started , otherwise an initial delay will be seen ? This is causing a major issue in embedded real time system. Thanks & Regards Manjula R SME â?? Audio/DSP Visteon Technical & Services Center , India Phone: +91-44-49477829 ------------------------------ Message: 3 Date: Thu, 26 Feb 2015 11:34:44 +0530 From: Arun Raghavan <arun@xxxxxxxxxxxx> To: General PulseAudio Discussion <pulseaudio-discuss at lists.freedesktop.org> Subject: Re: PA- Performance issue with PA read and CPU consumption in idle state Message-ID: <CACuU-+iC3=F94bR9tnZAh3T1Y7CQ5ydvwGa8Cac_No9TbSuiGg at mail.gmail.com> Content-Type: text/plain; charset=UTF-8 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. [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. > 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 . > 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
