similar to: fixed point code

?? hi ?Jean-Marc, ? thanks for your answer. But still I am struggling to find a reasonable upper limit for the RAM sizes. ? You say we need 4.5/9.0 kB for enc/dec per channel. But are those sizes really independent of any settings, like frame_size, bitrate, complexity, etc. ? ? at least in our configuration I find these requirements:? ?- native stack: < 2.1kB (enc or dec) measured by RealView

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

I checked it against the latest code in the git repository and it wasn't there. Mihai PS: if JM wants a @hates.ms address, I could prolly hook him up. Especially if he throws in some VAD code that's not "a hack" :) On Nov 5, 2007, at 2:08 PM, Tom Grandgent wrote: > Did you check it against the trunk in SVN? > > If it's not applied, and you can hook Jean-Marc up

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

Here some Blackfin inline assembly, mainly picked and adapted from speex. It's helps a little on my BF537 eval board. Julien -------- /** @file fixed_bfin.h @brief Fixed-point operations for the ADI BF5xx DSP family */ /* Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: -

I am having trouble understanding the stack allocation scheme when using a C55xx device. From what I can tell, the GLOBAL_STACK_SIZE is set in arch.h to 100,000 bytes (when using FIXED_POINT), which is then used in the ALLOC_STACK macro found in stack_alloc.h. This macro seems to say, if global_stack==0, then call celt_alloc_scratch, found in os_support.h, which in turn attempts to allocate (using

Dear Sir, Very glad to send E-mali to you , Im Annie. I have encountered some problems on the way of learning opus, so I would like to consult you. I found "global_stack" was not released after malloc, and malloc memory was too large.So what I want to ask you is whether "global_stack" malloc can have less memory, since the value "GLOBAL_STACK_SIZE" can be

Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net> --- libspeexdsp/resample.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libspeexdsp/resample.c b/libspeexdsp/resample.c index e32ca45..a19b997 100644 --- a/libspeexdsp/resample.c +++ b/libspeexdsp/resample.c @@ -85,7 +85,7 @@ static void speex_free (void *ptr) {free(ptr);} #ifdef FIXED_POINT #define

On Tue, Apr 15, 2014 at 12:33 PM, Peter Meerwald <pmeerw at pmeerw.net> wrote: > Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net> > --- > libspeexdsp/resample.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/libspeexdsp/resample.c b/libspeexdsp/resample.c > index e32ca45..a19b997 100644 > ---

#bug 1: besselI() for nu<0 and expon.scaled=TRUE #tested with R-devel (2007-06-17 r41981) x <- 2.3 nu <- -0.4 print(paste(besselI(x, nu, TRUE), "=", exp(-x)*besselI(x, nu, FALSE))) #fix: #$ diff bessel_i_old.c bessel_i_new.c #57c57 #< bessel_k(x, -alpha, expo) * ((ize == 1)? 2. : 2.*exp(-x))/M_PI #--- #> bessel_k(x, -alpha, expo) * ((ize == 1)? 2. :

As some of you know, I'm creating a hardware MDCT core. At the moment I'm working out the best way to create a lookup table for the trig values, as set up in mdct_init: /* trig lookups... */ for(i=0;i<n/4;i++){ T[i*2]=FLOAT_CONV(cos((M_PI/n)*(4*i))); T[i*2+1]=FLOAT_CONV(-sin((M_PI/n)*(4*i))); T[n2+i*2]=FLOAT_CONV(cos((M_PI/(2*n))*(2*i+1)));

void inverse_mdct_slow(float *buffer, int n) { =A0=A0 int i,j; =A0=A0 int n2 =3D n >> 1; =A0=A0 float *x =3D (float *) malloc(sizeof(*x) * n2); =A0=A0 memcpy(x, buffer, sizeof(*x) * n2); =A0=A0 for (i=3D0; i < n; ++i) { =A0=A0=A0=A0=A0 float acc =3D 0; =A0=A0=A0=A0=A0 for (j=3D0; j < n2; ++j) =A0=A0=A0=A0=A0=A0=A0=A0 // formula from paper: =A0=A0=A0=A0=A0=A0=A0=A0 //acc +=3D n/4.0f *

We were trying to normalize bands that didn't actually exist (e.g., the last band with 320-sample frames at 32kHz). Thanks to John Ridges for the report. --- libcelt/celt.c | 24 +++++++++++++++++------- 1 files changed, 17 insertions(+), 7 deletions(-) diff --git a/libcelt/celt.c b/libcelt/celt.c index 31d35f8..287c720 100644 --- a/libcelt/celt.c +++ b/libcelt/celt.c @@ -1137,6 +1137,7

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

Analogous to M_LN2 patch: the patch moves definition of M_PI from src/libFLAC/window.c and src/test_streams/main.c to include/share/compat.h -------------- next part -------------- A non-text attachment was scrubbed... Name: M_PI.patch Type: application/octet-stream Size: 1581 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130925/6a0afebe/attachment.obj

Actually opus-tools-0.2 has the same issue. Sincerely Forrest Zhang -------------- next part -------------- Add "#define FIXED_POINT 1" into the top of resample.c, outputs of resample are all zeros. Actually the data transform is required before/after calling speex_resampler_process_native(). diff -Naupr libopusenc-0.2.1-vanilla/src/resample.c libopusenc-0.2.1/src/resample.c ---

Hello, in this commit in celt_encoder.c https://git.xiph.org/?p=opus.git;a=commitdiff;h=652c4559f593d3aad78bd5c85a216eeae7859429 I see the note: + /* We should never see NaNs here. If we find any, then something really bad happened and we better abort + before it does any damage later on. If these asserts are disabled (no hardening), then the table + lookup a few lines below

Dear All, could someone please shed some light on the use of the .C or .Fortran function: I am trying load and running on R the following function // psi.cpp -- psi function for real arguments. // Algorithms and coefficient values from "Computation of Special // Functions", Zhang and Jin, John Wiley and Sons, 1996. // // (C) 2003, C. Bond. All rights reserved. // //

Hi all, im triyng to implement a bayesian model with R and c++. I have a strange problem. I can't reproduce the error with a small script and then i post the original one. The problem is after the line for(MCMC_iter2=0;MCMC_iter2<thin;MCMC_iter2++) For the first 34 iterations all work fine, after, all the simulations of mu_acc_P return an "nan". If i delete the line

.. And a version without the API changes. -------------- next part -------------- Index: libspeex/resample_sse.h =================================================================== --- libspeex/resample_sse.h (revision 0) +++ libspeex/resample_sse.h (revision 0) @@ -0,0 +1,128 @@ +/* Copyright (C) 2002-2008 Jean-Marc Valin + * Copyright (C) 2008 Thorvald Natvig + */ +/** + @file resample_sse.h +