similar to: A (minor) bug and a request

Hi Jean-Marc, As the self-appointed keeper of CELT_RESET_STATE (since I may be the only one actually using it) I've been kind of lax lately and have only now tried to reconcile it with the state structures in the 0.7.1 drop. I think (and feel free to contradict me here) that the following lines should be added to CELT_RESET_STATE in celt_encoder_ctl: st->fold_decision = 1;

Hello, for your consideration. The following patch moves the channel_pos() function from within the #if !defined(DISABLE_FLOAT_API). This change is required when compiling with FIXED_POINT and DISABLE_FLOAT_API defined. #### ### diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 3efab53..6f3eb53 100644 --- a/src/opus_multistream_encoder.c +++

Greetings, I have found that QCONST16(32.f, 10) yields different result (from gcc 4.4.7 ) when the code is compiled for TI C55 or C64 DSPs. gcc - result is 32767 TI compiler result is -32768 (C55 compiler version 4.4.1 and C6x compiler version 7.4.2) Although not in the current code, QCONST32(32.f, 26) results differ in similar fashion. Judging by the use #ifdef TI_C.. in the code base, these

Hi, My name is Riccardo Micci i downloaded the CELT source code and I compiled it under Windows. This is meant to be a preliminary study for my company's project. When i run CELT it encodes and decodes the file back saying "Encoder matches decoder!!". When i try to play the output though the result is just noise and clicks. The only changes I've applied are some #defines to

eds to drag in the source and header files from the libcelt directory into = the project and define HAVE_CONFIG_H is the project's pre-processor definit= ion. The tricky part is to build a config.h file. To get it to work on VS some = of the important settings include. =20 #define CELT_BUILD #define USE_ALLOCA #undef VAR_ARRAYS #undef restrict #undef HAVE_STDINT_H #undef inline #define

I got the approximation from a Google book: http://books.google.com/books?id=2CAqsF-RebgC&pg=PA385 Page 392, formula (10.33) Using this formula, you're right, hypergeom_gain() would *not* converge to 1 for large x, but would instead be gamma(1.25)/sqrt(sqrt(x)) which would approach zero. Now if the formula for the hypergeometric gain were instead gamma(1.5) * M(-.5;1;-x) / sqrt(x)

Speex tells me that the decoder is always 5 ms, but it says that the encoder is 5 ms for NB, 8.9375 ms for WB, and 10.90625 ms for UWB. Is there an extra frame of delay in the encoder that isn't otherwise accounted for? John Ridges Jean-Marc Valin wrote: > Quoting John Ridges <jridges at masque.com>: > >> I also need to know the precise delays from Speex but I used

By my reckoning the confluent hypergoemetric functions should have the following values: M(-.25;1;-.5) = 1.11433 M(-.25;1;-1) = 1.21088 M(-.25;1;-1.5) = 1.29385 M(-.25;1;-2) = 1.36627 M(-.25;1;-2.5) = 1.43038 M(-.25;1;-3) = 1.48784 M(-.25;1;-3.5) = 1.53988 M(-.25;1;-4) = 1.58747 M(-.25;1;-4.5) = 1.63134 M(-.25;1;-5) = 1.67206 M(-.25;1;-5.5) = 1.71009 M(-.25;1;-6) = 1.74579 M(-.25;1;-6.5) =

Thanks for the confirmation Jean-Marc. I kind of suspected from the comments that it was the confluent hypergoemetric function, which I was trying to evaluate using Kummer's equation, namely: M(a;b;x) is the sum from n=0 to infinity of (a)n*x^n / (b)n*n! where (a)n = a(a+1)(a+2) ... (a+n-1) But when I use Kummer's equation, I don't get the values in the "hypergeom_gain"

Thanks, I look forward to seeing what you find out. BTW, I was wondering if you tried replacing the SIG2WORD16 macro using the vqmovns_s32 intrinsic? I'm sure it would be faster than the C code, but in the grand scheme of things it might not make much difference. On 11/13/2015 12:15 PM, Jonathan Lennox wrote: >> On Nov 13, 2015, at 1:51 PM, John Ridges <jridges at masque.com>

Hi Jonathan, I'm sorry to bring this up again, and I don't want to beat a dead horse, but I was very surprised by your benchmarks so I took a little closer look. I think what's happening is that it's a little unfair to compare the ARM64 inline assembly to the C code, because looking at the C macros in "fixed_generic.h" for MULT16_32_Q16 and MULT16_32_Q15 you find

JM, I also need to know the precise delays from Speex but I used the SPEEX_GET_LOOKAHEAD control requests to determine them (plus the "speex_resampler_get_output_latency" function from the resampler). The returned values from the Speex lookahead request don't seem to match with the values you gave Alexander. Am I doing this wrong? Thanks, John Ridges speex-dev-request at

> On Nov 19, 2015, at 5:47 PM, John Ridges <jridges at masque.com> wrote: > > Any speedup from the intrinsics may just be swamped by the rest of the encode/decode process. But I think you really want SIG2WORD16 to be (vqmovns_s32(PSHR32((x), SIG_SHIFT))) Yes, you?re right. I forgot to run the vectors under qemu with my previous version (oh, the embarrassment!) Fixed forthcoming

Hi JM, When porting my project to the Mac, I found that the definition for "celt_int16" and "celt_uint16" are wrong for the MacOS X Framework in celt_types.h, and need to be changed to "int16_t" and "u_int16_t" respectively. Just thought you ought to know. John Ridges

Hi Jean-Marc, I could be way off base here, but it seems to me that line 115 in pitch.c in the function "pitch_downsample": x_lp[i] = SHR32(HALF32(HALF32(x[1][(2*i-1)]+x[1][(2*i+1)])+x[1][2*i]), SIG_SHIFT+2); should actually be: x_lp[i] += SHR32(HALF32(HALF32(x[1][(2*i-1)]+x[1][(2*i+1)])+x[1][2*i]), SIG_SHIFT+2); Sorry if I'm totally misreading things and just

Is there a document with some guidelines for setting up bricks with tcp or rdma transport? I'm looking at a new deployment where the storage cluster hosts connect via 10GigE, but clients are on 1GigE. Over time, there will be 10GigE clients, but the majority will remain on 1GigE. In this setup, should the storage bricks use tcp or rdma? If tcp is the better choice, and at some point in the

I?ve tried adding support for OPUS_FAST_INT64 to celt/arch.h, and I?ve found that this is indeed comparable in speed, if not a touch faster, than my inline assembly. I?ll submit patches for this. The inline assembly parts of my aarch64 patch set can thus be considered withdrawn. I haven?t yet tried replacing SIG2WORD16 (or silk_ADD_SAT32/silk_SUB_SAT32) with Neon intrinsics. That?s an obvious

It's been a while since I did the maths. M(-.5;1;-x) optimises something else, though it's not too far. I think it may be [M(-.25;1;-x)]^2 (or is it the sqrt?) that is supposed to be there. In any case, if there's a mismatch between the doc and the code, the code is the one likely to be correct. Jean-Marc John Ridges a ?crit : > I got the approximation from a Google book: >

On Nov 23, 2015, at 12:04 PM, John Ridges <jridges at masque.com<mailto:jridges at masque.com>> wrote: Hi Jonathan. I really, really hate to bring this up this late in the game, but I just noticed that your NEON code doesn't use any of the "high" intrinsics for ARM64, e.g. instead of: int32x4_t coef1 = vmovl_s16(vget_high_s16(coef16)); you could use: int32x4_t coef1

Something looks odd without your values (or the doc) because hypergeom_gain() should really approach 1 as x goes to infinity. But in the end, an approximation is probably OK because denoising is anything but an exact science :-) Jean-Marc Quoting John Ridges <jridges at masque.com>: > By my reckoning the confluent hypergoemetric functions should have the > following values: >