similar to: Frozen upper spectrum in WB VBR CNG

Great, thanks! That patch solved it. VBR without DTX seems to work perfectly now. If I enable DTX, there's still a little bit of buzz but it doesn't seem to last very long when it happens. I appreciate the quick fix! Tom Jean-Marc Valin (jean-marc.valin@hermes.usherb.ca) wrote: > > Yep, you found a bug and here's the patch. It should solve your problem > (using VBR

Hi, I've been using Speex in my voice-over-IP program on Win32, in wideband (16kHz) mode. I just starting using VBR recently and have run into something that might be a problem within Speex: If someone hasn't spoken for a little while, and the bitrate drops to very low, sometimes the high half of the spectrum becomes frozen with a looping sound. The bottom half of the spectrum is

Hi everyone, Some time ago, I sent a pull request <https://github.com/xiph/opus/pull/107> to the Opus github page. Jean-Marc asked me to post it to the mailing list so everyone can have a look at it. You can find the description and code changes below. Please let me know if you have any questions or concerns. Best regards Gustaf Ullberg In WebRTC, we would like to be able to

Thank you Mark. I agree and have now updated the pull request with a new commit, addressing your comments. Please take a look. /Gustaf On Fri, 5 Apr 2019 at 11:41, Mark Harris <mark.hsj at gmail.com> wrote: > On 2019-04-01 3:37, Gustaf Ullberg wrote: > > Hi everyone, > > > > Some time ago, I sent a pull request > > <https://github.com/xiph/opus/pull/107>

Hello, I'm try to run speex on some ARM processor. I'd like to cut away some speex features including VBR, ABR and preprocessor while still supporting VAD/DTX. But I've found some puzzles in the source code regarding VAD as below, 1) there are VAD related codes in the source file preprocess.c. Will VAD still work If I don't use the source file preprocess.c? 2)The speex manual

Hi Marc, Thanks for your quick response. So if VAD is enabled then VBR will be enable although it's a special VBR. How about take out the VAD code from the VBR and remove the code else? Lianghu On 10/24/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > > 1) there are VAD related codes in the source file preprocess.c. > > Will VAD still work If I

Hello, We are in the process of debugging a voice quality issue for a client of ours that is a VoIP services provider. The client uses a softphone that runs on a pjsip stack. When placing a call using the softphone, it negotiates the use of G729 codec with the remote endpoint (ptime = 20ms). The endpoint transmits RTP packets with encoded G729 payload. VAD/DTX is enabled. We see that the last

Hi there. I am having a little trouble understanding the frame sizes chosen by the codec. testenc_uwb.c from the speex-1.0 source distribution has a framesize of 640 hardcoded and makes use of this value exclusively. However, a mode query on the actual codec returns 320 as a framesize for this mode. int tmp; speex_mode_query(&speex_uwb_mode, SPEEX_MODE_FRAME_SIZE, &tmp);

Jean-Marc Valin wrote: >>In particular, (I'm not really sure, because I don't thorougly >>understand it yet) I don't think your jitterbuffer handles: >> >>DTX: discontinuous transmission. >> >> > >That is dealt with by the codec, at least for Speex. When it stops >receiving packets, it already knows whether it's in DTX/CNG mode.

I'm running a: for band in n w u do for quality in 0 1 2 3 4 5 6 7 8 9 10 do for complexity in 3 do for vad in "" "--vad" do for dtx in "" "--dtx" do echo speexenc -${band} --quality ${quality} --comp ${complexity} ${vad} ${dtx} input.${band}.wav

While porting opus 1.2.1 to esp32, my compiler had a grumble (error) about possible use of uninitialized variables in decide_dtx_mode() Existing code: --------SNIP--------- /* Decides if DTX should be turned on (=1) or off (=0) */ static int decide_dtx_mode(float activity_probability, /* probability that current frame contains speech/music */ int

Jean-Marc Valin wrote: >>Heh. I guess after playing with different jitter buffers long enough, >>I've realized that there's always situations that you haven't properly >>accounted for when designing one. >> >> > >For example? :-) > > I have a bunch of examples listed on the wiki page where I had written initial specifications:

On 2019-04-01 3:37, Gustaf Ullberg wrote: > Hi everyone, > > Some time ago, I sent a pull request > <https://github.com/xiph/opus/pull/107> to the Opus github page. > Jean-Marc asked me to post it to the mailing list so everyone can have a > look at it. > > You can find the description and code changes below. Please let me know > if you have any questions or

Hello: We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files as well as variable level noise-only test files. This issue can be reproduced with opus v1.1 using this command: ./opus_demo voip 16000 1 25000 -dtx input.bin

Per my conversation below with digium, are there any legal alternatives to digium's G729? It is out of date, and doesn't support VAD nor silence detection. Digium has stated that they have no plans to update it anytime soon. VAD/Silence is a big deal with major carriers and we are having to fight a battle to get them to make special arrangements to turn off VAD/Silence in their

Yes, good point. I added the checking of prev_mode for Silk DTX to avoid using stale data from the Silk state. The PR is updated, and I'm attaching an updated patch. /Gustaf On Tue, 9 Apr 2019 at 12:42, Mark Harris <mark.hsj at gmail.com> wrote: > On 2019-04-08 4:55, Gustaf Ullberg wrote: > > Thank you Mark. > > > > I agree and have now updated the pull request

I'm working on an opus codec for the asterisk voip app. Googling DTX found: https://bugs.chromium.org/p/webrtc/issues/detail?id=4559 To paraphrase, if there's silence long enough, opus enters Celt-only mode, which has no DTX. Is this still correct ? And is the suggested work-around effective? sean -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, When we pass around 9K samples of only ambient noise (no voice), the encoder which is enabled FEC+DTX is detecting only some 140 frames as non-voice (returning only TOC, no frame content). We were expecting all or more to be identified as non-voice. Our idea was to check how the decoder re-generates the original ambient noise during the silence duration (when we feed NULL to decoder) when

Hello, I am trying to use the DTX feature of speex to tell if the user is speaking. I have VBR, DTX and VAD turned on, but the function speex_encode always returns a non-zero value. It is my understanding that it should return a zero value when the encoder detects silence? Could anyone give me any clues to help figure out why this isn't working for me? I am using the 1.13 version of speex on

System: Linux 2.4.25, glibc-2.3.2, gcc-3.2.3 (weird palindrome there), on a Williamette core Pentium 4 (1.6Ghz) system. I've tried both speex 1.1.5 release, and the current CVS (which self-IDs as 1.1.4), and the result is the same. I suspect some funk in the use of the SSE intrinsics macros. Backtrace: #0 0x40024594 in filter_mem2_10 (x=0x805f31c, _num=0x8061fb8, _den=0x8061fe4,