similar to: st->nb_loudness_adapt removal patch

What happens if you change that line: if (cumul_gain > 262144) to use a smaller value? What value works OK (if any)? One more thing, when things go wrong, do they eventually go back to normal or does the codec never recover? It's unavoidable that the audio goes bad for a short period of time because of the long-term predictor. Jean-Marc On 2010-01-14 05:57, Frank Lorenz wrote: >

Hi Jean-Marc, yes, problem exists in narrowband-mode, too. I already twiddled with max_gain, but did not have real success. I changed line 337 of ltp.c (function pitch_gain_search_3tap_vq) if (sum>best_sum && gain_sum<=max_gain) { to if (sum>best_sum && gain_sum<max_gain) { -- that stabilizes speex for 2000 Hz and 2200 Hz input on quality setting 7 (23800

Hi Jean Marc, I found that the AGC API and algorithm has changed in svn head trunk. Is it safe to use it? Or is it for testing purpose only? You also said that VAD in svn is broken in a previous post, is it related to the AGC change? or can we mix the old VAD algorithm with the new AGC safely? kind regards, fredo

Hi, The attached patch fixes an incistency in my earlier patch. Whereas the rest of the AGC ctls are in dB, GET_AGC_GAIN was linear. This patch fixes that. It also changes the API for _GET and _SET_AGC_LEVEL to use a int32 instead of a float, meaning we don't need to do a API change when we get a fixed point AGC. Best regards, Thorvald -------------- next part -------------- ---

Hi, Ref the disucussion on IRC yesterday; here's a patch which makes a bit more data from the analysis of the preprocessor and the echo canceller available. For the preprocessor: - Size of power spectrum. - Power spectrum and noise estimate of the previous frame. These are given as squared values, so sqrt() to get values in the 0->32767 range. - Current amplification level

Most asm statements clobber ASTAT bits (shifts, maxes, etc...) but do declare the register as clobbered. Same thing with CC in a few places. Some places make an attempt at clobbering some hardware loop registers, but it's very incomplete compared with how many asm statements actually use hardware loops. Signed-off-by: Mike Frysinger <vapier at gentoo.org> --- libspeex/bfin.h

Hi, So I see in: split_cb_shape_sign_unquant this call is going wrong: ind[i] = speex_bits_unpack_unsigned(bits, params->shape_bits); ind as a way negative number- basically this should return bet. 0-255 or somesuch right? So seems like I need to reset speex at this point if if (ind[i] > 256) like the note says. So I guess my question is is this range still valid? also what is the

Hi, Does someone know if I could use SpeexPreprocessState::loudness or SpeexPreprocessState::loudness2 to create a VU meter. And if so, how? <p>Thanks, Tom Moers --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word

During hardware and network impairment testing, I sometimes just hold down a DTMF key to keep the audio busy. I have found that if I restart the receiver while the transmitter is still encoding DTMF, the receiver plays out a different tone, until the DTMF key goes off an on again. Also, today I captured some Speex frames during a tone (but not including the start of the tone). When I later fed

On Tue, 2018-06-05 at 10:23 -0700, Joe Perches wrote: > Perhaps these are simpler as > > #define __inline__ inline > #define __inline inline Currently, there are these uses of inline variants in the kernel $ git grep -w inline | wc -l 68410 $ git grep -w __inline__ | wc -l 503 $ git grep -w __inline | wc -l 57 So it seems it's also reasonable to sed all uses of __inline to

The definition of granule position for an OggDirac elementary stream isn't the same as theora. Index: tools/oggz_tools.c =================================================================== --- tools/oggz_tools.c (revision 3759) +++ tools/oggz_tools.c (working copy) @@ -454,7 +454,15 @@ iframe = granulepos >> granuleshift; pframe = granulepos - (iframe << granuleshift);

A widely used platform doesn't bother to have C99 integer types, so this allows building with it. Reported by sirlemonhead on IRC. Index: src/tools/oggz_tools.c =================================================================== --- src/tools/oggz_tools.c (revision 3827) +++ src/tools/oggz_tools.c (working copy) @@ -450,7 +450,7 @@ dg->pt = (iframe + pframe) >> 9;

>What happens if you make SPEEX_PREPROCESS_SET_ECHO_SUPPRESS_ACTIVE less >aggressive. Does it end up with too much echo or it just doesn't realise >that it's in double-talk conditions? My impression is that it does not make much difference on the timing to set this parameter less aggressive. Depending on the how loud the near end is talking it may detect double talk but most

This small patch will make st->Zlast = Zframe, to allow applications access to an estimate of the signal-to-noise level. This used to be in there earlier, but was removed when Zlast was no longer used to compute Pframe. -------------- next part -------------- Index: preprocess.c =================================================================== --- preprocess.c (revision 10007) +++

Johan Nilsson a ?crit : >> There's also a parameter to control the maximum amount of >> suppression allowed: SPEEX_PREPROCESS_SET_NOISE_SUPPRESS : noise >> suppression SPEEX_PREPROCESS_SET_ECHO_SUPPRESS : echo suppression >> when there is no local talk >> SPEEX_PREPROCESS_SET_ECHO_SUPPRESS_ACTIVE: echo suppression in >> double-talk > > Yes, I am

Johan Nilsson a ?crit : >> What happens if you make SPEEX_PREPROCESS_SET_ECHO_SUPPRESS_ACTIVE less >> aggressive. Does it end up with too much echo or it just doesn't realise >> that it's in double-talk conditions? > > My impression is that it does not make much difference on the timing to > set this parameter less aggressive. Depending on the how loud the

Hi, Here are the next two patches for the data export. speex_get_psd should be applied after speex_get_agc_gain (sent in previous mail). It allows applications to get the power spectrum for the signal and the noise estimate. speex_get_prob should be applied last. It allows fetching the speech probability of the current frame (the value that the _PROB_START and _PROB_CONTINUE parameters are

<body bgcolor="#ffffff" background="https://img.web.de/v/p.gif" class="bgRepeatYes" style="background-repeat: repeat; background-color: rgb(255, 255, 255); color: rgb(0, 0, 0); font-size: 9pt; padding-left: 0px;" ><p>Hi Jean-Marc,</p> <p>&nbsp;</p> <p>yes, I tested with floating point. It is only a fixed point

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

>> I think the residual echo estimation is fairly reliable but I do not know >> how to use this to improve Pframe and in that way solve our main problem >> with the gain during near end talk. > > How can you tell that the residual echo estimation is reliable? in any > case, I suspect that the whole Pframe idea might have to be revised > (i.e. computing it completely