[opus] 1.1 Much slower on Raspberry Pi

[Stuart Marsden]

Resampling to 48khz speeds them both up but the disparity is about the
same: 2.609 to 3.69.

Best Regards,

Stuart Marsden


On 17 December 2013 17:04, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote:

> Christian,
>
> Complexity 0, 6kbps:
>
> 0.9.14 Speed 5.204
> 1.1 Speed 5.218
>
> A slight win on that run but they vary enough to say about the same. At
> 64kbps
>
> 0.9.14 Speed 6.35
> 1.1 Speed 6.001
>
> I get more variation on these so I would say they are quite close and the
> difference may not be statistically significant.
>
> I notice my sample is 44.1khz which is not optimal so it may be the
> re-sampling which is contributing. I will adjust in audacity and try the
> comparison again.
>
> Stuart
>
> Best Regards,
>
> Stuart Marsden
>
> Tactical Communications Consultant
> FinMars Consulting Ltd
> UK: +441865589833
> Finland: +358453046287
>
>
> On 17 December 2013 16:53, Christian Hoene <christian.hoene at symonics.com>wrote:
>
>> Hi Stuart,
>>
>>
>>
>> what happens if you do the tests with complexity 0?
>>
>>
>>
>> With best regards,
>>
>>
>>
>> Christian
>>
>>
>>
>>
>>
>> *Von:* opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] *Im Auftrag
>> von *Stuart Marsden
>> *Gesendet:* Dienstag, 17. Dezember 2013 15:40
>> *An:* opus at xiph.org
>> *Betreff:* Re: [opus] 1.1 Much slower on Raspberry Pi
>>
>>
>>
>> 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/0a75dae4/attachment-0001.htm