similar to: Do VAD work on silk?

Hi Dmitry, So it's not explicitly in your report, but it looks like the crash is due to a divide-by-zero at: min_coef = silk_DIV32_16( silk_int16_MAX, silk_RSHIFT( psSilk_VAD->counter, 4 ) + 1 ); which happens because counter is -16 (which means (-16 >> 4) + 1 == 0). Now, this could be caused by an integer wrap-around, but it should only happen after encoding around

Hi Jean-Marc, We're exposing the opus_internal_flags data structure so that we can access the value assigned to prevSignalType. Here's a snippet of our code: error = opus_encoder_get_internal_flags(vad->opus, &internalflags); if (error != OPUS_OK) { return OPUSVAD_OPUS_ERROR; } cur_signal_type = internalflags.prevSignalType; if

Hi Jean-Marc, gdb out is "Program terminated with signal 8, Arithmetic exception." most likely this division by zero. you're right, this crash is reproduce on seq number 4294967265 (20ms rtp packet). This is about 994 days. "Jean-Marc Valin" <jmvalin at jmvalin.ca> писал(а):Hi Dmitry, > >So it's not explicitly in your report, but it looks like the crash

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, >

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

Stack: (gdb) bt #0 0x0000000000aaf38a in silk_VAD_GetNoiseLevels (pX=pX at entry=0x7f26740297a0, psSilk_VAD=psSilk_VAD at entry=0x15897c38) at silk/VAD.c:315 #1 0x0000000000aa4a9d in silk_VAD_GetSA_Q8_sse4_1 (psEncC=0x15897c18, pIn=<optimized out>) at silk/x86/VAD_sse.c:177 #2 0x0000000000a9f92b in silk_encode_do_VAD_FLP (psEnc=psEnc at entry=0x15897c18) at

Hi Jean-Marc, Thank you for the valuable feedback. You're correct in that we focused on enabling this just for SILK. Because our solutions are focused on voice, we did not explore doing the same in CELT mode, but we can certainly look into the details of analysis.c. Regarding the concern of exposing internals, do you have a specific proposal in mind? We've been sharing this patch with

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

Hi, 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. /*********************************/ /* Speech Probability Estimation */ /*********************************/ SA_Q15 = silk_sigm_Q15( silk_SMULWB( VAD_SNR_FACTOR_Q16, pSNR_dB_Q7 ) -

Hi Peter, There's two main issues with a patch like the one you're proposing. First, the data is only valid when SILK is being used and is essentially undefined in CELT mode. The second issue is that by exposing internals, it makes it impossible to improve these algorithms since it would break API compatibility. I'm not fundamentally against trying to expose some information, but

Hi Peter, Can you say a little bit more about what you're doing exactly with the information you're exposing and how? unfortunately, I don't have a concrete proposal in mind right now. That's in part because I don't quite understand the use case, but also because it's really hard to expose this kind of information in a way that both avoids breaking application with new

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

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

I have difficulties to understand how to use Silk GNC. I have enabled GNC (and VAD) something like this: param.setting.vad = 1; param.setting.cng = 1; param.setting.plc = 1; param.setting.penh = 1; status = pjmedia_codec_opus_set_default_param(&config, &param); I used debugger and printf to see that code executes in Opus CNG.c silk_CNG function noise generation loop. But still I cannot

Hi, I'm interested in speech recognition and it occurred to me to try to use VAD to automatically detect the start of speech prior to feeding the stream to the recognition engine. Speex has a preprocessor capability which presumably could be used for this, but I did not see similar in my quick perusal of Opus docs. First, is this is a dumb idea for some reason? If not, should I just use

Hello, I am studying different VAD (and Speech/Music detection) methods and find the one based on GRU very interesting (the one implemented in Opus 1.3). Is there a documentation on how to calculate the vector of input features [25 elements] and a description on how the GRU was trained (RFC, Presentation, ...etc.)? (I am not able to understand all the content of the source code in analysis.c )

Hello Jean-Marc et al: On 07/06/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > - Is there a reference somewhere (other than the source itself) that > > explains how the latest VAD algorithm works? > > Read the source, Luke :-) (sorry) Okay. I had to ask :-) > > > - Is it possible to obtain the VAD status of a Speex stream > >

Hello, I am trying to use the preprocessor VAD to encode at lower bitrate during silence periods. I am able to run the preprocessor and get the VAD flag for each frame, and I am quite happy with it's performance. I would like to know how to pass the preprocessor VAD flag to speex encoder -- basically, i want to force the encoder to generate comfort noise when preprocessor detects silence.

Hello Jean-Marc: On 08/06/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > Either one. The question is: If we treat the software like a black > > box, and we feed in PCM audio, we get Speex encoded data out. Where is > > the information that indicates whether the encoded data contains > > speech or not? The API has a "get VAD status", but it

Hi, I had the same experience. The VAD done in the encoder does not seem to work very well at all. However, the VAD done by speex_preprocess() works much better. You will also get better results if you enable the denoiser, I think. peex_preprocess_ctl(preprocess, SPEEX_PREPROCESS_SET_DENOISE, &denoise_enabled); speex_preprocess_ctl(preprocess, SPEEX_PREPROCESS_SET_VAD,