[opus] Opus decoding performance on ARM devices
jmvalin at jmvalin.ca
Fri Sep 5 12:40:51 PDT 2014
Oh, I forgot to mention that right now probably the part of the code
that would most need asm is the MDCT/FFT code.
On 05/09/14 03:56 AM, Dan Nilsson wrote:
> Thank you for your response. I pulled yesterday to commit
> da97db1ca1f92592af3534c9a2596da0e9a009ca, added a bunch of more defines to
> my compile options, and assembled & linked in
> Performance jumped up from about 4.8 Mb/s to 5.3 Mb/s on the same device,
> so it is improvement. Not sure what other tweaks there would be to try,
> but if it could match the tremolo decoder, we could probably throw that
> out entirely which would be very nice.
> On 04/09/14 19:40, "Jean-Marc Valin" <jmvalin at jmvalin.ca> wrote:
>> Hi Dan,
>> I suggest you try the code in git master, which has further ARM
>> optimizations compared to 1.1.
>> On 04/09/14 08:00 AM, Dan Nilsson wrote:
>>> Hi everyone,
>>> I have lately been evaluating the performance of various audio decoders,
>>> particularly for ARM devices (Cortex A8 / A9). The context is audio
>>> playback in a game engine, and thus decoding performance is of
>>> Looking at Opus versus Vorbis on a Cortex A9 smartphone, the numbers
>>> approximately like this:
>>> Vorbis (tremolo decoder)
>>> 9.3 Mb PCM/s
>>> Opus (libopus 1.1)
>>> 4.8 Mb PCM/s
>>> The Opus audio is encoded approximately 120 kbps (and the vorbis file
>>> higher bitrate). On ARM devices this far I get Opus decoded at about
>>> the rate (and on x86 they are about on par).
>>> Should I be able to squeeze more performance out of it? Or do those
>>> numbers look about what should be expected? What I really want to know
>>> if Opus could potentially run faster than Vorbis for equivalent audio.
>>> I also must mention I am cross compiling with a different build system.
>>> have attempted different sets of compilation defines. Latest run
>>> the following:
>>> opus mailing list
>>> opus at xiph.org
More information about the opus