[opus] 1.1 Much slower on Raspberry Pi
Stuart Marsden
stuartmarsden at finmars.co.uk
Tue Dec 17 06:40:06 PST 2013
I have compiled myself the previous version of libopus to find out if it
was a regression or something I was doing wrong in compiling. It looks like
it has got slower since 0.9.14. I have recompiled everything with these
CFLAGS natively on the Pi: "-O2 -pipe -march=armv6j -mtune=arm1176jzf-s
-mfpu=vfp -mfloat-abi=hard". These seem to be the recommended settings. I
had assumed that opusenc would not be taking that much CPU but having
re-compiled I have made up some of the loss but not all.
So on the same file with complexity 10 at bitrate 6kbps (floating point), I
see the following speeds (x realtime):
libopus 0.9.14 opus-tools 0.1.2 Speed 2.289
libopus 1.1 opus-tools 0.1.2 Speed 1.887
libopus 1.1 opus-tools 0.1.8 Speed 1.667
Same file with complexity 10 at bitrate 64kbps (floating point), I see the
following speeds:
libopus 0.9.14 opus-tools 0.1.2 Speed 2.639
libopus 1.1 opus-tools 0.1.2 Speed 2.193
libopus 1.1 opus-tools 0.1.8 Speed 2.069
So it seems both libopus and opus-tools have become slower on the Raspberry
PI somewhere between 0.9.14 and 1.1. This seems to be for both SILK and
CELT or at least 6 and 64kbps. Opus-tools is also contributing to the
slowdown. I would be hitting the library direct when I implement so that is
off less interest to me but still worth looking at. I did not run lots of
repeats of each test but when I did they only varied by about 0.05 so
natural variation does not account for it.
Maybe the advertised speed ups were only for more modern ARM targets but it
is still a shame to see it get slower on this target.
Stuart Marsden
Best Regards,
Stuart Marsden
Tactical Communications Consultant
FinMars Consulting Ltd
UK: +441865589833
Finland: +358453046287
On 17 December 2013 12:48, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote:
> Christian,
>
> I will give 64kbit/s a try and post the figures. My own project is voice
> only and requires low bitrate so was hoping that it was just the way I was
> compiling and not an actual regression in speed for SILK. The raspberry PI
> is quite a cheap and handy reference platform though the ARM side is fairly
> underpowered but has a great GPU. It also has no audio in which is a pain
> for playing with codecs but it does support USB soundcards. I was wondering
> if a microcontroller like the Cortex-M range might be able to encode and
> that seemed possible extrapolating from the Pi results but this speed
> regression if it is real would kill that hope.
>
> I should also probably try and compile the same version from the Raspbian
> repos myself and if I also see a big slowdown then it is something wrong
> with the way I am compiling. I am not a deb expert but it seemed like the
> only optimisation they were using was -O2 but perhaps there is something
> else set. Do not want to claim a regression when it may be my own fault.
>
> Thanks for your response.
>
>
> Best Regards,
>
> Stuart Marsden
>
>
> On 17 December 2013 11:04, Christian Hoene <christian.hoene at symonics.com>wrote:
>
>> Hi Stuart,
>>
>>
>>
>> you are compressing it at 6kbit/s. Then, then SILK mode is probability
>> used and the Silk mode is much faster than CELT. Do you also some figures
>> at 64kbit/s?
>>
>>
>>
>> It is strange that Opus 1.1 got slower in the Silk mode – may the
>> speech/voice selection adds some overhead. I would be interested in seeing
>> the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1.
>>
>>
>>
>> With best regards,
>>
>>
>>
>> Christian Hoene
>>
>>
>>
>> PS:
>> I also though on using Raspberry PI as a reference platform for testing
>> the speech of Opus on a ARM processor. For measuring the speech
>> of Opus on Intel CPUs, the MARSS86.org simulator might be appropriate.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Von:* opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] *Im Auftrag
>> von *Stuart Marsden
>> *Gesendet:* Montag, 16. Dezember 2013 14:03
>> *An:* opus at xiph.org
>> *Betreff:* [opus] 1.1 Much slower on Raspberry Pi
>>
>>
>>
>> I have just started trying Opus with a view to using it in a project. I
>> am interested in embedded hardware and tried it on the Raspberry Pi using
>> the raspbian distro.
>>
>>
>>
>> The version of libopus in the repos is 0.9.14. I installed this and tried
>> encoding 2 minutes of speech from a librevox recording. It managed this at
>> a respectable pace for complexity 10:
>>
>>
>>
>> Skipping chunk of type "LIST", length 76
>>
>> Encoding using libopus 0.9.14 (audio)
>>
>> -----------------------------------------------------
>>
>> Input: 44.1kHz 1 channel
>>
>> Output: 1 channel (1 uncoupled)
>>
>> 20ms packets, 6kbit/sec VBR
>>
>> Preskip: 356
>>
>>
>>
>> Encoding complete
>>
>> -----------------------------------------------------
>>
>> Encoded: 2 minutes and 0.02 seconds
>>
>> Runtime: 50.9 seconds
>>
>> (2.358x realtime)
>>
>> Wrote: 111194 bytes, 6001 packets, 123 pages
>>
>> Bitrate: 6.78414kbit/s (without overhead)
>>
>> Rate range: 2.8kbit/s to 12kbit/s
>>
>> (7 to 30 bytes per packet)
>>
>> Overhead: 8.47% (container+metadata)
>>
>>
>>
>> And even faster on complexity 0:
>>
>>
>>
>> Skipping chunk of type "LIST", length 76
>>
>> Encoding using libopus 0.9.14 (audio)
>>
>> -----------------------------------------------------
>>
>> Input: 44.1kHz 1 channel
>>
>> Output: 1 channel (1 uncoupled)
>>
>> 20ms packets, 6kbit/sec VBR
>>
>> Preskip: 316
>>
>>
>>
>> Encoding complete
>>
>> -----------------------------------------------------
>>
>> Encoded: 2 minutes and 0.02 seconds
>>
>> Runtime: 23.72 seconds
>>
>> (5.059x realtime)
>>
>> Wrote: 106598 bytes, 6001 packets, 123 pages
>>
>> Bitrate: 6.47779kbit/s (without overhead)
>>
>> Rate range: 2.4kbit/s to 13.6kbit/s
>>
>> (6 to 34 bytes per packet)
>>
>> Overhead: 8.83% (container+metadata)
>>
>>
>>
>> I saw the 1.1 release notes and it said speed improvements on ARM so
>> thought I would try. I downloaded from opus-codec.org and compiled
>> directly on the Pi. It has however turned out a lot slower. Complexity 10
>> barely can encode in realtime:
>>
>>
>>
>> Skipping chunk of type "LIST", length 76
>>
>> Encoding using libopus 1.1 (audio)
>>
>> -----------------------------------------------------
>>
>> Input: 44.1kHz 1 channel
>>
>> Output: 1 channel (1 uncoupled)
>>
>> 20ms packets, 6kbit/sec VBR
>>
>> Preskip: 356
>>
>>
>>
>> Encoding complete
>>
>>
>> -----------------------------------------------------
>>
>> Encoded: 2 minutes and 0.02 seconds
>>
>> Runtime: 1 minute and 53 seconds
>>
>> (1.062x realtime)
>>
>> Wrote: 110743 bytes, 6001 packets, 123 pages
>>
>> Bitrate: 6.70782kbit/s (without overhead)
>>
>> Instant rates: 2.8kbit/s to 11.6kbit/s
>>
>> (7 to 29 bytes per packet)
>>
>> Overhead: 9.13% (container+metadata)
>>
>>
>>
>> And is also much slower at complexity 0:
>>
>>
>>
>> Skipping chunk of type "LIST", length 76
>>
>> Notice: Using resampling with complexity<10.
>>
>> Opusenc is fastest with 48, 24, 16, 12, or 8kHz input.
>>
>>
>>
>> Encoding using libopus 1.1 (audio)
>>
>> -----------------------------------------------------
>>
>> Input: 44.1kHz 1 channel
>>
>> Output: 1 channel (1 uncoupled)
>>
>> 20ms packets, 6kbit/sec VBR
>>
>> Preskip: 316
>>
>>
>>
>> Encoding complete
>>
>>
>> -----------------------------------------------------
>>
>> Encoded: 2 minutes and 0.02 seconds
>>
>> Runtime: 36 seconds
>>
>> (3.334x realtime)
>>
>> Wrote: 106945 bytes, 6001 packets, 123 pages
>>
>> Bitrate: 6.45466kbit/s (without overhead)
>>
>> Instant rates: 2.4kbit/s to 12.8kbit/s
>>
>> (6 to 32 bytes per packet)
>>
>> Overhead: 9.45% (container+metadata)
>>
>>
>>
>> I tried compiling it as fixed point and it is slightly faster but no
>> where near the older version. At complexity 10:
>>
>>
>>
>> Skipping chunk of type "LIST", length 76
>>
>> Encoding using libopus 1.1-fixed (audio)
>>
>> -----------------------------------------------------
>>
>> Input: 44.1kHz 1 channel
>>
>> Output: 1 channel (1 uncoupled)
>>
>> 20ms packets, 6kbit/sec VBR
>>
>> Preskip: 356
>>
>>
>>
>> Encoding complete
>>
>>
>> -----------------------------------------------------
>>
>> Encoded: 2 minutes and 0.02 seconds
>>
>> Runtime: 1 minute and 42 seconds
>>
>> (1.177x realtime)
>>
>> Wrote: 110686 bytes, 6001 packets, 123 pages
>>
>> Bitrate: 6.70402kbit/s (without overhead)
>>
>> Instant rates: 2.4kbit/s to 11.2kbit/s
>>
>> (6 to 28 bytes per packet)
>>
>> Overhead: 9.13% (container+metadata)
>>
>>
>>
>>
>>
>> I have tried different compiler options but nothing has brought the speed
>> back up.
>>
>>
>>
>> Any advice on the compiler flags or why I should be seeing such a big
>> speed regression?
>>
>>
>>
>> Stuart Marsden
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20131217/1211a25b/attachment-0001.htm
More information about the opus
mailing list