<div dir="ltr"><div>Sorry, long holiday weekend in America.<br>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 where the 16-bit value is stored in a 32-bit int without sign-extension e.g. 0x00008b3b), but that doesn't seem to be the case here.<br></div><div>The problem is even worse when opus_int is defined as 16-bit in the platform - SA_Q15 overflows to negative right here with a similar effect<br></div><div style="margin-left:40px">speech_nrg = silk_SQRT_APPROX(speech_nrg);<br>SA_Q15 = silk_SMULWB(32768 + speech_nrg, SA_Q15);</div><div style="margin-left:40px"><br></div>I can't speak for the logic where the speech energy gets doubled. It obviously seems intentional but I don't know why. Maybe so that smoothing is performed at a constant rate regardless of whether framesize is 10 or 20ms?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 26, 2017 at 8:07 PM, Chandrakala Madhira <span dir="ltr"><<a href="mailto:chandrakala.madhira@soctronics.com" target="_blank">chandrakala.madhira@soctronics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">Hi,<br><br>Can anyone let me know if this is a bug?<br><br><div><span name="x"></span>Thank you,<br>Chandrakala<span name="x"></span><br></div><br><hr id="m_-8088624264559517178zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Logan Stromberg" <<a href="mailto:loganstromberg@gmail.com" target="_blank">loganstromberg@gmail.com</a>><br><b>To: </b>"Chandrakala Madhira" <<a href="mailto:chandrakala.madhira@soctronics.com" target="_blank">chandrakala.madhira@<wbr>soctronics.com</a>><br><b>Cc: </b><a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a><br><b>Sent: </b>Wednesday, November 22, 2017 12:12:39 PM<div><div class="h5"><br><b>Subject: </b>Re: [opus] Reg an issue with smoothing factor in VAD implementation<br><br><div dir="ltr">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?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 21, 2017 at 8:34 PM, Chandrakala Madhira <span dir="ltr"><<a href="mailto:chandrakala.madhira@soctronics.com" target="_blank">chandrakala.madhira@<wbr>soctronics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">Hi Logan,<br><br>Please find attached the input stream we are using testing.<br><br><div><span></span>Thank you,<br>Chandrakala<span></span><br></div><br><hr id="m_-8088624264559517178m_-6614939233426569233zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Chandrakala Madhira" <<a href="mailto:chandrakala.madhira@soctronics.com" target="_blank">chandrakala.madhira@<wbr>soctronics.com</a>><br><b>To: </b>"Logan Stromberg" <<a href="mailto:loganstromberg@gmail.com" target="_blank">loganstromberg@gmail.com</a>><br><b>Cc: </b><a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a><br><b>Sent: </b>Wednesday, November 22, 2017 9:53:55 AM<div><div class="m_-8088624264559517178h5"><br><b>Subject: </b>Re: [opus] Reg an issue with smoothing factor in VAD implementation<br><br><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">Hi Logan,<br><br>Below is the configuration I am using. The remaining
parameters have defaults. The stream is a 16KHz stream. The bitrate
selected is 16KHz. As the thread have size limitations, I will try to attach the stream in next mail. At
125th frame of this stream, the probability (SA_Q15) value is 0x0000859c. This value is
treated as a negative number in step-3.<br><br>-e voip 16000 1 16000 -framesize 10 -cvbr Input/dg105_16k.wav Output/dg105_16k_16000Fs_mono_<wbr>16000bps_10ms_vbr_voip.bit<br><br><span></span>Thank you,<br>Chandrakala<span></span><br><br><div><span></span>Thank you,<br>Chandrakala<span></span><br></div><br><hr id="m_-8088624264559517178m_-6614939233426569233zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Logan Stromberg" <<a href="mailto:loganstromberg@gmail.com" target="_blank">loganstromberg@gmail.com</a>><br><b>To: </b><a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a><br><b>Sent: </b>Tuesday, November 21, 2017 2:38:16 AM<br><b>Subject: </b>Re: [opus] Reg an issue with smoothing factor in VAD implementation<br><br><div dir="ltr"><div><div>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:<br></div><div><br></div><div>Sample rate = 48000</div><div>Channels = 1</div><div>Application = OPUS_APPLICATION_AUDIO</div><div>Bitrate = 24 KB/s<br></div><div>Force Mode = MODE_SILK_ONLY</div><div>Signal Type = OPUS_SIGNAL_AUTO</div><div>Complexity = 10</div>Frame size = 480 samples (10ms)<br></div><div><br></div><div>No errors came up in encoding. Chandrakala, are these the encoding parameters that you believe should trigger the error?</div><div><br></div><div>- Logan<br></div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br><br>
We are looking at the VAD implementation used in opus. We are looking at
the code where speech probability is calculated based on which SNR is
estimated. Below is the part of the code I am talking about.<br><br>
/*****************************<wbr>****/<br>
/* Speech Probability Estimation */<br>
/*****************************<wbr>****/<br>
SA_Q15 = silk_sigm_Q15( silk_SMULWB( VAD_SNR_FACTOR_Q16, pSNR_dB_Q7 ) -
VAD_NEGATIVE_OFFSET_Q5 ); // step1: Calculate speech probability :
comment by me<br><br>
/* Power scaling */<br>
if( speech_nrg <= 0 ) { // step2: update speech probability based on speech energy : comment by me<br>
SA_Q15 = silk_RSHIFT( SA_Q15, 1 );<br>
} else if( speech_nrg < 32768 ) {<br>
if( psEncC->frame_length == 10 * psEncC->fs_kHz ) {<br>
speech_nrg = silk_LSHIFT_SAT32( speech_nrg, 16 ); // Energy is doubled here : comment by me<br>
} else {<br>
speech_nrg = silk_LSHIFT_SAT32( speech_nrg, 15 );<br>
}<br><br>
/* square-root */<br>
speech_nrg = silk_SQRT_APPROX( speech_nrg );<br>
SA_Q15 = silk_SMULWB( 32768 + speech_nrg, SA_Q15 );<br>
}<br><br>
/* Smoothing coefficient */<br>
smooth_coef_Q16 = silk_SMULWB( VAD_SNR_SMOOTH_COEF_Q18, silk_SMULWB(
(opus_int32)SA_Q15, SA_Q15 ) ); // step3: Update the smoothing factor
based on speech probability : comment by me<br><br>
if( psEncC->frame_length == 10 * psEncC->fs_kHz ) {<br>
smooth_coef_Q16 >>= 1;<br>
}<br><br>
Here, in step1, Speech probability is calculated whose value is expected
to be within [0, 1) in Q15 format. Then based on the speech energy
levels, in Step2, the probability is updated whose value shall also lie
between [0, 1). Later in Step3, the smooth coeff is calculated. This
code do not have any issue when the frame size is more than or equal to
20msec. But, if the frame size is 10ms, then in step2, the energy is
doubled (this may be done because the original Silk code is for 20ms. To
convert the energy for 20ms, it could have been doubled). When this is
done the probability which is updated in step2 becomes more than 1. When
this is used in multiplication in Step3, the value is treated as a
negative number because its a 32x16 multiplication. This is will result
in a negative smooth coefficient. Please let me know if this is a bug.<br><br><br>
Thank you,<br>
Chandrakala</blockquote>
</div></div></div>
<br>______________________________<wbr>_________________<br>opus mailing list<br><a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/opus" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/opus</a><br></div><br></div></div></div></div><br></div></div></blockquote></div><br></div>
</div></div></div><br></div></div></blockquote></div><br></div>