[opus] opus Digest, Vol 109, Issue 8

Mon Feb 26 12:51:24 UTC 2018

We have found that it is possible to achieve a 30 to 50% reduction in MHz 
requirement for implementation of OPUS on Cortex M4 compared to the public 
version (v1.3 beta/v1.2.1).
For the CELT configuration you mention (complexity 0, 16kHz, mono, 20ms) we 
are measuring a 4ms encode time and a 3ms decode time for that platform 
(32kbit/s).

An important issue that I haven't seen much discussion on is on how audio 
quality degrades with complexity settings. I suspect the above configuration 
choice is driven by the desire to minimise complexity.
If the application is voice then the SILK codec would provide better audio 
particularly below 20kbit/s.

Cliff Parris

-----Original Message----- 
From: opus-request at xiph.org
Sent: Saturday, February 24, 2018 12:00 PM
To: opus at xiph.org
Subject: opus Digest, Vol 109, Issue 8

Send opus mailing list submissions to
opus at xiph.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xiph.org/mailman/listinfo/opus
or, via email, send a message with subject or body 'help' to
opus-request at xiph.org

You can reach the person managing the list at
opus-owner at xiph.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of opus digest..."

Today's Topics:

   1. Re: [EXTERNAL] Re: Developing OPUS on TI CC3220 (Thomas Daede)
   2. Re: [EXTERNAL] Re:  Developing OPUS on TI CC3220
      (Rodriguez, Vince)

----------------------------------------------------------------------

Message: 1
Date: Fri, 23 Feb 2018 09:51:50 -0800
From: Thomas Daede <tdaede at mozilla.com>
To: opus at xiph.org
Subject: Re: [opus] [EXTERNAL] Re: Developing OPUS on TI CC3220
Message-ID: <cb912328-586c-74f4-1844-af63607a8017 at mozilla.com>
Content-Type: text/plain; charset=utf-8

On 02/23/2018 07:47 AM, Rodriguez, Vince wrote:
> Currently decode takes 16~22 ms and encode is ~13 ms. What is the best
> way to try to reduce this time? Also, unsure why encode is taking less
> time than decode...

Last month a user posted some benchmarks on a STM32F4, which is a the
same core as your cc3220 but at 168MHz rather than 80Mhz. Here's the
results:

http://lists.xiph.org/pipermail/opus/attachments/20180114/a0340dfa/attachment-0012.png

Based on that it seems that your decode should take about ~10ms, so
it'll be a bit of a squeeze to get full duplex in. But your numbers are
significantly worse. Are you running out of XIP flash? Do you have all
the flash accelerators and caches enabled?

------------------------------

Message: 2
Date: Fri, 23 Feb 2018 20:47:35 +0000
From: "Rodriguez, Vince" <vince.rodriguez at ti.com>
To: Jean-Marc Valin <jmvalin at jmvalin.ca>, "opus at xiph.org"
<opus at xiph.org>
Subject: Re: [opus] [EXTERNAL] Re:  Developing OPUS on TI CC3220
Message-ID: <b9b0a3c18627458bb075f9aa89e8c6c0 at ti.com>
Content-Type: text/plain; charset="utf-8"

Jean-Marc,

Thanks for the quick reply.

Using your comments, I was able to get my implementation to be much closer 
to working. Decode taking ~8 msecs and encode is ~13 ms.

I noticed with decode, if I use a file saved on the device, I can decode it 
in 4 ms. This is the timing I need to make the bi-directional work.

Looking into how my encoder is setup. It seems I can isolate my overflow 
condition to the Silk implementation. On the first call to Encode with silk, 
the codec does a malloc, and I get a null pointer returned.

I guess I'm a little hazy on the memory requirements. We have a heap, that 
holds the state of the codec (~25 kB), but do we also need to malloc other 
memory to encode? Or does the codec use the heap allocated to do all 
encoding?

Thanks!

VR

-----Original Message-----
From: Jean-Marc Valin [mailto:jmvalin at jmvalin.ca]
Sent: Friday, February 23, 2018 11:12 AM
To: Rodriguez, Vince; opus at xiph.org
Subject: Re: [EXTERNAL] Re: [opus] Developing OPUS on TI CC3220

On 02/23/2018 10:47 AM, Rodriguez, Vince wrote:
> Currently decode takes 16~22 ms and encode is ~13 ms. What is the best
> way to try to reduce this time? Also, unsure why encode is taking less
> time than decode...

Tried running a profiler?

> I've also noticed if I change my encoder to silk only, I get a Heap
> overflow... I have dynamically allocated a heap for the codec, got the
> size using the api and used encode init so that the memory is
> allocated to my created heap. I have 30k currently in heap, since the
> return of get  size was ~25 kB. This seems to happen when I change the
> application as well. :/

SILK and CELT use exactly as much heap since the only heap Opus needs is the 
encoder state which holds both the SILK and the CELT state. What stack 
allocator did you end up choosing? If you used the pseudo-stack, then that 
allocates a lot of heap memory. If not, then maybe you have some sort of 
collision between the stack and heap?

>     i32error = opus_encoder_init(sOpusEnc, 16000, 1,
> OPUS_APPLICATION_RESTRICTED_LOWDELAY);

OPUS_APPLICATION_RESTRICTED_LOWDELAY will force CELT-only mode here, 
regardless of other options.

>    opus_encoder_ctl(sOpusEnc, OPUS_SET_FORCE_CHANNELS(1));//Mono

No need to force mono since you're only encoding one channel (this does 
nothing).

Jean-Marc

------------------------------

Subject: Digest Footer

_______________________________________________
opus mailing list
opus at xiph.org
http://lists.xiph.org/mailman/listinfo/opus

------------------------------

End of opus Digest, Vol 109, Issue 8
************************************

---
This email has been checked for viruses by AVG.
http://www.avg.com 