Are there any tests for opus CPU load for decoding? Do different parameters (especially bitrate) affect cpu load? I'm most interested in recent real-world smartphone use cases for music. I'm interested for my x86-64 gaming PC as well, but it seems FLAC is far more power efficient so I should stick with FLAC if I have the option.
I found some links but don't know how useful they are.
While there is a room for performance optimizations it was already 3 generations of smartphones and tablets those can decode Opus using less than 5% of CPU resources (and that is only a single core) resulting in very long battery life.
So, no use worrying about CPU resources? Compared to other things done on a smartphone (Twitter, web browsing, powering the screen) I expect that 5% on one core is small. Similarly, it would appear that it's optimized enough that hardware acceleration is not a high priority?
Actual data from rockbox: https://www.rockbox.org/wiki/CodecPerformanceComparison
The rockbox data implies a 1.5-2x higher CPU power requirement for Opus than MP3/LAME. But some/all of these devices are ancient (iPod classic) rather than a <3 year old cell phone SoC. I'm assuming that the higher % (realtime column) is better, lower decode time is better, and lower MHz is better.
I'm assuming that the higher % (realtime column) is better, lower decode time is better, and lower MHz is better.
Yes. And given that dual ARMv4 at 90 MHz can decode Opus at more than realtime (albeit with a highly optimized decoder) it probably doesn't mean much on octacore ARM with newer cores at an order of magnitude higher clockspeed, it probably doesn't matter much.
Am I wrong in thinking that these measurements should be irrelevant to any modern hardware? Decoding (in realtime) doesn't even register on my 12 year old rig.
It is vaguely relevant for things like games which may want to be able to stream dozens or even hundreds of compressed audio streams in real time, rather than decoding them all ahead of time to memory.
The rockbox decoder is actually not that well optimized. I started working on it ~10 years back but got busy and never came back to it. I think with good optimization is would be similar in load to AAC/Vorbis.
On Android, I suspect a lot of devices will use a very low power DSP decoder anyway, not ARM.
foobar uses ARM software decoders where possible, or whatever the system provides if it's something like USAC. This mainly so it can boast huge numbers from its decoder speed benchmark, where system decoders frequently are limited to only real time or near real time decoding speed.
Isn't it also relevant for power consumption and hence battery life? Or is audio decoding already such a microscopic part of the big picture?
Just got a used Pixel 2 and did some tests. Opus + Bluetooth is much lower power than the other tests I ran.
12h54: VLC, playing Opus (stereo) music @ 128 kbps on shuffle via bluetooth (Ambient display enabled) - (Ambient Display used 9%, VLC used 40%, I think the OS/battery isn't identifying the correct battery levels). Wifi on, airplane off, but no cell network connected. (911 should have been okay)
3h18: VLC, airplane mode (after the first 10-30 minutes). Playing 1080p blu-ray (AVC / m2ts) of My Neighbor Totoro on loop, subtitles on, non-DTS-HD audio track. volume 80%
5h26: YouTube, max quality, muted, plus some standby (on top of the 5h26)
That's 774m of Opus vs. 326m of muted YouTube. Safe to say anything you do with the screen on will be much worse than Opus playback. 2.37x more battery for Opus.
^^ I think that probably has more to do with the difference between playing a file in VLC and running the whole Youtube app, where probably the audio decode is a small fraction of the total energy.
I think you'll find that for most mobile devices, driving the screen hardware, including the backlighting, is way more battery power than any decoding, even video decoding.
Someone will have to make a benchmark that streams and decodes YouTube videos while the screen is powered off and locked, to determine if this is a major factor.
I'm guessing the video decode is probably being done by dedicated DSP hardware on most modern phones.
Whereas most audio decode barely registers on a semi-modern smartphone CPU.