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. 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. 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. 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 . It is ARM cortex A9 at 800 MHz Thanks & Regards Manjula R Message: 4 Date: Mon, 9 Feb 2015 18:19:38 +0530 From: Arun Raghavan <arun@xxxxxxxxxxxx<mailto:arun@xxxxxxxxxxxx>> To: General PulseAudio Discussion <pulseaudio-discuss at lists.freedesktop.org<mailto:pulseaudio-discuss at lists.freedesktop.org>> Cc: "Viswambharan, Vibin \(V.\)" <vvibin at visteon.com<mailto:vvibin at visteon.com>>, "Sampath, NishathKumaran \(N.\)" <nsampat2 at visteon.com<mailto:nsampat2 at visteon.com>> Subject: Re: PA- Performance issue with PA read and CPU consumption in idle state Message-ID: <CACuU-+i2YKLcWL81QS-zBL3riU0X_+7RBfkBg-cFcrP8VaejWw at mail.gmail.com<mailto:CACuU-+i2YKLcWL81QS-zBL3riU0X_+7RBfkBg-cFcrP8VaejWw at mail.gmail.com>> Content-Type: text/plain; charset=UTF-8 On 4 February 2015 at 16:13, Radhakrishnan, Manjula (M.) <rmanjula at visteon.com<mailto:rmanjula at visteon.com>> wrote: > > Hi , > > > > We are observing performance issue with Pulse Audio in our embedded infotainment platform. I'm assuming embedded => ARM below. > > To brief on the usage of PA in this platform , Pulse Audio is used for Audio routing from an Audio source provider to another Audio Source sink using Pulse Audio using the Null sink and Null sink.monitor. > > > > The audio path is as below. > > Audio source provider -> Pulse Audio Nullsink (eg. Route_test) -> Pulse Audio Null source (eg. Route_test.monitor) -> Audio router to sink > > > > There are two behavioral issues observed in the Pulse Audio , below is the description of the issues. > > > > 1. The Audio source provider creates a Pulse stream and writes to the Pulse Audio Nullsink before the Audio router thread has opened the Pulse Stream for reading from nullsink.monitor . In this condition , from the application Audio router , PA reader thread opens the PA stream and calls the PA read API , it is blocked for more than 1 sec inside PA read API before the first read is successful. > > > > What could cause this delay in the first PA read ? Does the writer starting to write to PA first cause a delay/block on the reader when it eventually becomes active ? The delay sounds like a bug. It would be interesting to debug/profile and see where the time is spent. > > 2. For the same issue above, on further debugging , On the PA reader side , the PA stream open is called and the stream is kept open always by the reader. In this condition , the delay is no longer observed in the first PA read. But this causes an impact on the CPU. > > When the PA stream is always open and no reads are done ,significant CPU usage is observed , PA process consumes 21 - 23 % and the threaded-m1 consumes 5 â?? 7 % CPU even when there is no read/write happening in PA server. > > > > Why is this high CPU observed and how to optimize the CPU , is there any configuration where the PA stream can be opened and still have low CPU consumption ? > > Please provide your insights on the two queries. It would be interesting to know what CPU this is, what frequency it is running at, and what kind of scaling might be happening (ideally, there should be no scaling while you're measuring CPU consumption, and you peg the frequency at some sensible number). Where the CPU utilisation is going would best be determined by profiling (perf top is your friend). Things that could be going wrong vary from bad drivers that wake up the CPU too often, to not having your resampler (speex?) or PulseAudio compiled with the correct CPU optimisations (speex needs to be compiled with correct flags depending on whether you want it to work on float or int samples, and PA has optimisations for ARMv6 and NEON as well). Regards, Arun ------------------------------ Subject: Digest Footer _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss at lists.freedesktop.org<mailto:pulseaudio-discuss at lists.freedesktop.org> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ------------------------------ End of pulseaudio-discuss Digest, Vol 46, Issue 19 ************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150212/5bbd72eb/attachment.html>
