Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CPU Benchmarks for Opus decode (ARM especially)? (Read 4543 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CPU Benchmarks for Opus decode (ARM especially)?

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.

https://hydrogenaud.io/index.php?topic=101764.msg839554#msg839554

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.

https://www.ti.com/lit/ug/tidua45/tidua45.pdf?ts=1619579537459

https://www.mediamagictechnologies.com/opus-codec-optimization/

https://en.wikipedia.org/wiki/Opus_(audio_format)#Hardware

https://wiki.hydrogenaud.io/index.php?title=Opus#Hardware_support

https://hydrogenaud.io/index.php?topic=104916

https://hydrogenaud.io/index.php?topic=86580.msg802525#msg802525

 

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #1
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #2
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #3
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #4
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #5
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #6
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?

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #7
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #8
^^ 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. 

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #9
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.

Re: CPU Benchmarks for Opus decode (ARM especially)?

Reply #10
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.