Arjan, I did even more analysis on this subject and better understand what is causing the CPU burdon.
In Moblin, PulseAudio is configured to perform re-sampling using the 'src-linear' method based on the config in /etc/pulse/daemon.conf. Re-sampling happens when you have an audio source that is encoded at a different sample rate than PulseAudio's default sample rate. Example would be PulseAudio is set to run at 48Khz, but I have an mp3 that is encoded at 44.1Khz. (Pretty common.) In daemon.conf, there a number of methods allowed for re-sampling. I tried some of the different versions and it seems that it would be better to have the re-sample method set to 'ffmpeg' as a default as most people say it is of higher quality than 'src-linear' and I experienced a 10% drop in CPU usage by PulseAudio. (It was taking as much as 25% on my Atom Z520 based HW) Regardless, it takes at least 15% of the CPU to do the sample-rate conversion which is unfortunate, but necessary when you have dissimilar sampling rates. Do you think PulseAudio daemon.conf was set to 'src-linear' on purpose for Moblin or is this just a default that was inherited and should possibly be changed in Moblin to better work with the Atom? Chris On Wed, Oct 14, 2009 at 8:52 PM, Arjan van de Ven <ar...@linux.intel.com>wrote: > Chris Healy wrote: > >> I was doing some performance analysis of my Atom based Moblin system while >> decoding audio and noticed a considerable amount of CPU taken up while >> decoding an AAC stream using gstreamer. >> >> After further analysis, I noticed that "libspeexdsp" seemed to be the >> culprit for the CPU consumption. >> >> I grabbed the speex source RPM from the Moblin repos and took a look at >> how >> it was being compiled. I'm not an expert with building this code, but it >> seems to me that there is nothing in either the spec file or the config >> that >> forces it to be built with SSE enabled. >> >> I'm seems to me that it should be built with "-O3" and "-msse" flags set >> to >> take advantage of the DSP functions provided by SSE3 which I believe is >> available in ALL Atom processors. >> >> libspeexdsp seems to be able to utilize these DSP like functions in our >> Atom >> chips, provided that we use the flags. >> >> Am I way off in left field with this analysis or am I on to something that >> could substantially reduce our audio decoding burden? >> > > > we actually provide system wide compiler flags which do include the ssse3 > flag. > > However, for DSP like code often hand coded assembly (using sse) tends to > be the part > that provides a lot of the value. > > (for "normal" code sse provides value in terms of floating point; sse is > faster than x87 > style floating point) > _______________________________________________ Moblin dev Mailing List dev@moblin.org To manage or unsubscribe from this mailing list visit: http://lists.moblin.org/listinfo/dev or your user account on http://moblin.org once logged in. For more information on the Moblin Developer Mailing lists visit: http://moblin.org/community/mailing-lists
