similar to: Small mistake in celt_types.h for MacOS X

Is this a common warning? The decoder doesn't return an error on it, but I see it a lot in my test application on windows. It is non existent on my linux box. I haven't tried mingw yet. please note that I'm using visual studio 2008 w/the vcproj that Bjoern Rasmussen made for 0.5.2 (w/some file references removed) at the moment and it is giving a lot of C4554 warnings

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

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>

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) =

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)

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

One other minor thing: I notice that in the inline assembly the result (rd) is constrained as an earlyclobber operand. What was the reason for that?

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

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"

Nit: in dual_inner_prod_sse, why not do both horizontal sums at the same time? As in: xsum1 = _mm_add_ps(_mm_movelh_ps(xsum1, xsum2), _mm_movehl_ps(xsum2, xsum1)); xsum1 = _mm_add_ps(xsum1, _mm_shuffle_ps(xsum1, xsum1, 0xf5)); _mm_store_ss(xy1, xsum1); _mm_store_ss(xy2, _mm_movehl_ps(xsum1, xsum1)); --John

> 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

Jean-Mark, Tim, Could either of you expound on the following comment in cwrs.c? /*If _k==0, the following do-while loop will overflow the buffer.*/ ---------------------------------------------------------------- ...because the following do-loop does overflow the buffer when k=126 k=2; do _u[k]=(k<<1)-1; while(++k<len); Thanks, MikeH -------------- next

These were used because the entropy coder originally came from outside libcelt, and thus did not have a common type system. It's now undergone enough modification that it's not ever likely to be used as-is in another codec without some porting effort, so there's no real reason to maintain the typedefs separately. Hopefully we'll replace these all again somedate with a common set

Since you're already set up for benchmarks, I would ask if you could benchmark the difference between using and not using the ARM64 inline assembly. I believe the original justification on ARMv7 for the assembly was the processor's panoply of multiply instructions and their long cycle times. It seems to me that the ARM64 processor is much more like an x86 one, where using a

I realize this is ancient history, but I am trying to compile Ver 8.1 (from the download page) using Fixed Point and am getting compile errors as follows: argument of type "celt_sig *" is incompatible with parameter of type "celt_int16 *" libcelt81_orig_DSP/libcelt celt.c line 321 1304524612394 19769 argument of type "celt_sig *" is incompatible

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

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

Hi Jean-Marc, I'd just like to put in a vote that I wish you'd left in the high-complexity mode in CELT (with the assumption that it could be conditionally compiled out for the IETF standard codec). It seems like it makes it a more useful standalone codec in Xiph's arsenal, and from my own viewpoint I'm uncertain I'll be able to use the SILK codec because of the patent

Congrats to the team for 0.10.0. It sounds really good in the tests I've done so far. I'm really looking forward to the 1.0 release. One question though: could you explain briefly the difference between VBR and unconstrained VBR? And, in my case, the $64K question: is there any situation where CELT could produce more data than specified by nbCompressedBytes when encoding? Thanks