This is a continuation of my previous post. Based on the feedback I decided to do two things; investigate the strange FLAC high CPU usage with FFmpeg, and get more accurate measurements.
It turns out that GStreamer flac parser uses four times more CPU than FFmpeg’s decoder. Thanks to perf, I was able to quickly figure out the biggest offenders: GStreamer’s horrible bitstream reader (GST_BIT_READER_READ_BITS) was by far the worst.
This is on my laptop just running the parser (filesrc ! flacparse ! fakesink), in total it was taking 2.67s.
After reading the code and trying different things, I decided to go for something similar to what FFmpeg is doing, and I also borrowed pieces of the architecture-specific optimizations, now it even looks ok:
And it takes 0.81s.
But how much would this affect battery life on the N900?
Smart battery script
I tried different ideas, and after refreshing myself on statistics I wrote this script in Ruby that runs all the tests, gathers the battery capacity in a separate thread, and finally generates a report per test. Much easier than before.
Since I’m already working on FLAC, I decided to also apply some patches that split the decoder from the parser, and optimizations from Måns Rullgård (good thing I grabbed them because he seems to have left the project and deleted his repos).
So, yeah, much better now
But how credible are these results? Well, judge by yourself, listed below are the raw measurements, the samples are the differences in capacity (mAh) measured each 10 minutes, from which the drain and battery life are calculated.
== baseline ==
samples: 3, 3, 3, 3, 4, 5
== av flac ==
samples: 9, 8, 8, 8, 7, 8, 7
== flac ==
samples: 11, 11, 11, 11, 11, 11
== av mp3 ==
samples: 11, 11, 11, 11, 11, 10
== nokiamp3 ==
samples: 12, 12, 12, 12, 12, 12
== av vorbis ==
samples: 10, 11, 11, 10, 11, 11
== vorbis ==
samples: 19, 18, 18, 19, 18, 19