similar to: Reg an issue with smoothing factor in VAD implementation

Sorry, long holiday weekend in America. I can say with pretty high certainty that there is an overflow occurring and it is flipping smooth_coef_Q16 to be negative when it probably shouldn't be. I had originally thought it was only an issue where it was overflowing the 15th bit but not the 16th, which might still preserve the intended value for operations that ignore the sign bit (in cases

Yes, yes, I can reproduce it now, but only on platforms that define a 16-bit int by default (SA_Q15 is an opus_int rather than opus_int32). What system are you compiling this for? On Tue, Nov 21, 2017 at 8:34 PM, Chandrakala Madhira < chandrakala.madhira at soctronics.com> wrote: > Hi Logan, > > Please find attached the input stream we are using testing. > > Thank you, >

Hi Chandrakala, Logan, Can you confirm that the attached patch fixes the overflow problem? Koen, can you confirm the fix makes sense? Cheers, Jean-Marc On 11/27/2017 12:10 PM, Logan Stromberg wrote: > Sorry, long holiday weekend in America. > I can say with pretty high certainty that there is an overflow occurring > and it is flipping smooth_coef_Q16 to be negative when it probably

Just for fun, I tried to reproduce such an overflow. I turned on all debug macros, assertions, and checked arithmetic and then encoded 2 hours of mixed speech/audio with these parameters: Sample rate = 48000 Channels = 1 Application = OPUS_APPLICATION_AUDIO Bitrate = 24 KB/s Force Mode = MODE_SILK_ONLY Signal Type = OPUS_SIGNAL_AUTO Complexity = 10 Frame size = 480 samples (10ms) No errors came

Hi, Can anyone let me know if this is a bug? Thank you, Chandrakala ----- Original Message ----- From: "Logan Stromberg" <loganstromberg at gmail.com> To: "Chandrakala Madhira" <chandrakala.madhira at soctronics.com> Cc: opus at xiph.org Sent: Wednesday, November 22, 2017 12:12:39 PM Subject: Re: [opus] Reg an issue with smoothing factor in VAD

Created corresponding unit test, and the optimization is bit exact with C function. --- silk/SigProc_FIX.h | 7 ++- silk/arm/arm_silk_map.c | 12 ++++ silk/arm/inner_prod_aligned_arm.h | 58 +++++++++++++++++++ silk/arm/inner_prod_aligned_neon_intr.c | 66 ++++++++++++++++++++++ silk/enc_API.c

Created corresponding unit test, and the optimization is bit exact with C function. This optimization speeds up SILK encoder on NEON as following. Fixed-point: Complexity 0-5: 0% Complexity 6-7: 6% Complexity 8-9: 10% Complexity 10: 8% Got similar results on floating-point. --- silk/NSQ_del_dec.c | 6 +- silk/SigProc_FIX.h | 4

--- silk/macros.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/silk/macros.h b/silk/macros.h index 1ba614a..e1e05b9 100644 --- a/silk/macros.h +++ b/silk/macros.h @@ -48,14 +48,14 @@ POSSIBILITY OF SUCH DAMAGE. /* (a32 * (opus_int32)((opus_int16)(b32))) >> 16 output have to be 32bit int */ #if OPUS_FAST_INT64 -#define silk_SMULWB(a32, b32)

This patch adds a macro abstracting the condition under which the silk math macros use opus_int64-based calculations rather than opus_int32. No substantive change, but will make it easier to adjust if additional such platforms are found in the future. --- silk/macros.h | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/silk/macros.h b/silk/macros.h index

Hi OPUS, The macro Silk_LSHIFT_SAT32( ) doesn?t generate the correct saturated 32 bit results, at least in some cases e.g: Silk_LSHIFT_SAT32( 0x4000, 17) = 0x7ffe000; Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130610/be3f808f/attachment.htm

On Mon, Apr 24, 2017 at 5:52 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 24/04/17 08:03 PM, Linfeng Zhang wrote: > > Tested on my chromebook, when stride (channel) == 1, the optimization > > has no gain compared with C function. > > You mean that the Neon code is the same speed as the C code for > stride==1? This is not terribly surprising for an IIRC

Greetings list, I am working on a project on which we wish to use Speex with Google Automatic Speech Recognition (ASR) to transcribe Speex audio being sent on to Google ASR service and return us the text of the spoken audio in the Speex audio stream. However, Google ASR's Speex support requires the off-standard Speex-with-header-byte format, and my group cannot find any worthwhile

Greetings list, I am working on a project on which we wish to use Speex with Google Automatic Speech Recognition (ASR) to transcribe Speex audio being sent on to Google ASR service and return us the text of the spoken audio in the Speex audio stream. However, Google ASR's Speex support requires the off-standard Speex-with-header-byte format, and my group cannot find any worthwhile

Hello, This is a first patch which add macros for ARMv5E. Also, I copy headers from other files and add company name, tell me if I'm wrong. Also, if you have any question or comment about it, feel free to contact me. Best regards, -- Aur?lien Zanelli Parrot SA 174, quai de Jemmapes 75010 Paris France -------------- next part -------------- diff --git a/celt/fixed_arm5e.h

Ping for comments. Thanks, Linfeng On Wed, Apr 26, 2017 at 2:15 PM, Linfeng Zhang <linfengz at google.com> wrote: > On Tue, Apr 25, 2017 at 10:31 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> > wrote: > >> >> > A_Q28 is split to 2 14-bit (or 16-bit, whatever) integers, to make the >> > multiplication operation within 32-bits. NEON can do 32-bit x

Hi Jean-Marc, Thanks! Please find the 2 updated patches which only optimize stride 2 case and keep the bit exactness. They have passed our internal tests as usual. Thanks, Linfeng On Mon, May 15, 2017 at 9:36 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > Sorry for the delay -- I was actually trying to think of the best option > here. For now, my

On Tue, Apr 25, 2017 at 10:31 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > > > A_Q28 is split to 2 14-bit (or 16-bit, whatever) integers, to make the > > multiplication operation within 32-bits. NEON can do 32-bit x 32-bit = > > 64-bit using 'int64x2_t vmull_s32(int32x2_t a, int32x2_t b)', and it > > could possibly be faster and less

--- silk/NSQ_del_dec.c | 37 +++++++++++++------------------------ silk/mips/NSQ_del_dec_mipsr1.h | 3 ++- 2 files changed, 15 insertions(+), 25 deletions(-) diff --git a/silk/NSQ_del_dec.c b/silk/NSQ_del_dec.c index aff560c..aaa1fca 100644 --- a/silk/NSQ_del_dec.c +++ b/silk/NSQ_del_dec.c @@ -31,6 +31,8 @@ POSSIBILITY OF SUCH DAMAGE. #include "main.h" #include

--- silk/NSQ_del_dec.c | 37 +++++++++++++------------------------ silk/mips/NSQ_del_dec_mipsr1.h | 3 ++- 2 files changed, 15 insertions(+), 25 deletions(-) diff --git a/silk/NSQ_del_dec.c b/silk/NSQ_del_dec.c index aff560c..aaa1fca 100644 --- a/silk/NSQ_del_dec.c +++ b/silk/NSQ_del_dec.c @@ -31,6 +31,8 @@ POSSIBILITY OF SUCH DAMAGE. #include "main.h" #include

Hi Linfeng, Sorry for the delay -- I was actually trying to think of the best option here. For now, my preference would be to keep things bit-exact, but should there be more similar optimizations relying on 64-bit multiplication results, then we could consider having a special option to enable those (even in C). Cheers, Jean-Marc On 08/05/17 12:12 PM, Linfeng Zhang wrote: > Ping for