On Tue, 2014-07-22 at 16:50 +0900, JoonCheol Park wrote: > Hello, > > > I'd like to optimize pulseaudio settings on my system (arm based). > and I'm planning to try test with several change settings to find best > settings on my system. > To do this, I want to know what is the best way to measure the > performance of pulseaudio for each settings. Especially I'd like to > check the cpu consumption or latency. > > > I tried to googling for this and reviewed code briefly to find some > unit tests for performance checking.. > * oprofile - looks profile each function in point of developer view > * top or ptop or perf top - difficult to check exact start/end time of > pulse Why would you need to check the exact start and end time of pulseaudio? If you do cpu usage benchmarking, you typically start pulseaudio, and then start one or more clients that do streaming with parameters that you've decided for the benchmark. When the streams are running, you check the cpu usage with some tool, e.g. top (remember to lock the cpu speed first so that cpu speed scaling doesn't mess up the benchmarking results). It doesn't matter when pulseaudio started. You mentioned that you'd like to "check the latency". There's no such thing as "the latency". Maybe you mean the minimum latency that pulseaudio is able to provide without drop-outs on specific hardware for a single stream with specific parameters? I don't know what would be the best way to find that out, but running e.g. "pacat --verbose --latency-msec=something /dev/zero" is one way to try to get some idea of the minimum latency. pacat will print a message whenever there's an underrun in the client buffer, so you can try different values for --latency-msec to find the lowest value that doesn't cause client underruns. For server-side underruns, you can watch the pulseaudio log for messages like this: I: [alsa-sink-ALC269VC Analog] alsa-sink.c: Underrun! I: [alsa-sink-ALC269VC Analog] alsa-sink.c: Increasing minimal latency to 4.00 ms -- Tanu
