Yaroslav Halchenko wrote: >> I'm trying to improve mediaplayer, and a big part of that is improving >> performance. If you figure out why pulseaudio eats 6% CPU, that'd be >> great! Also, it mysteriously eats much more than that when music is >> being played back. > well -- whenever it is playing my wild guess is that it resamples it > from 44100 to hardware supported 48000, or smth like that... for that I > guess it would need some cpu cycles
Right, but why so many more than gstreamer + alsa? Pulseaudio says it's using floating point for the resampler, but the docs say it supports fixed point resampling. > > the mystery in my case is that pulseaudio doesn't play anything but does > consume significant amount of cpu cycles > There is a configuration setting that tells it to constantly send '0' to the sound card even when there's no input. This lowers the latency of playback, and might prevent clicking an popping. I haven't played with it. I think it's turned on right now. I don't understand why doing that takes 6% of the CPU. I'd think it would just repeatedly toss the same pointer into alsa without touching memory... Maybe context switches are more expensive than I'd guess. >> My theory is that it's doing unnecessary signal resampling and >> int->float->int conversions. Having mediaplayer bypass pulseaudio and >> talk directly to alsa saves a lot of CPU. > ie it works like that for sure (ie have you tried it)? > Yes. It's much faster. I posted a patch. On figuring out the float conversion stuff, GStreamer definitely converts to floats before going to pulse. It doesn't to do this for ALSA. The "theory" part is that it's unnecessary given pulse's current plugins, etc; I forced mine to keep everything fixed point, and it got *much* slower. The logs I base this on are here: https://docs.openmoko.org/trac/ticket/1614#comment:3 -Rusty _______________________________________________ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
