similar to: Please reinstate CELT_SET_SIGNALLING_REQUEST

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>

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

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

> 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

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"

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

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?

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

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

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

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

Hi all, One question that I hope someone on the list just knows the answer to without having to delve too deeply into the code: How does UWB mode divvy up the bandwidth and pack it in the bitstream? I know from the documentation that WB mode codes the first 0-4K kHz band as a Narrowband packet, and then adds on the 4-8 kHz band coded separately (so that a NB decoder can decode a WB bitstream

Hi Jean-Marc, I was just wondering if maybe you would consider a "blog-like" text file in the codebase where you just jot down your thoughts about why you are making a change, and where you think you are headed. For example, I noticed today that you completely removed the pitch prediction code. It would be nice to know if you did that because you're moving away from using it as

> On Nov 16, 2015, at 4:42 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > > I haven?t yet tried replacing SIG2WORD16 (or silk_ADD_SAT32/silk_SUB_SAT32) with Neon intrinsics. That?s an obvious next step. This doesn?t show any appreciable speed difference in my tests, but the code is obviously better by inspection (all three of these map directly to a single Aarch64

Well, I found a solution and posted it on the appdb's page of Red Alert 3. http://appdb.winehq.org/objectManager.php?sClass=version&iId=14371 Here's a copy of the informations I posted on the Red Alert's Appdb webpage : > Thanks to raphael, here's a mini "how to play on LAN to RA3 with Wine + windows users, when the LAN is a VPN" > > My hostname, in