similar to: Delays estimation in Speex algorithms

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

Quoting 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? Oh, delay = frame_size + lookahead If you have a frame size of 20 ms, then there's no choice but

Hi, I want to do a careful measure of mic-to-net and net-to-spkr delays in sip media engine and to make it really precise I need to know delays, introduced by Speex algorithms. In particular, I'm interested in delays of: 1) encoder in NB, WB and UWB modes, 2) decoder (I guess it should be 0?) 3) resampler. I think it varies depending on input rate to output rate ratio. Any generic formula or

Quoting John Ridges <jridges at masque.com>: > 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

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

First patch fixes two typos in manual. Second patch adds few notes about latency, as promised. Hopefully I haven't added any typos and grammar errors :) On Wed, Jul 1, 2009 at 8:02 PM, Alexander Chemeris<Alexander.Chemeris at sipez.com> wrote: > Thank you for clarification. I attached a patch which (IMHO) > makes it more clear for everyone who just read Doxygen > docs.

1. What to do with the last frame that is smaller then frame size? During encoding, the last frame is often smaller than the required frame size. In the sample code, proper number of zeros are padded at the end. So if I don't want those padded zero after decoding, I assume that it is up to me to keep track of the number of zeros. Is it right? 2. What does SPEEX_GET_LOOKAHEAD do? How to

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)

Thank you for clarification. I attached a patch which (IMHO) makes it more clear for everyone who just read Doxygen docs. Resampler latency docs wording was just ambiguous IMO, so I made it more robust to fast reading. On Wed, Jul 1, 2009 at 5:16 PM, Jean-Marc Valin<jean-marc.valin at usherbrooke.ca> wrote: > Alexander Chemeris a ?crit : >> On Tue, Jun 30, 2009 at 4:38 AM,

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

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"

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

> Ok, here is cleaned up and fixed version. > > * Function is named speex_get_num_frames() now and return > number of frames, as you suggested. > * WB layers sizes are taken from wb_skip_table[], while NB frame > sizes are calculated with speex_mode_query(). Looking better. Just make sure to remove the stuff that isn't C99-compatible (e.g. // comments). > I've

> 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

----- Original Message ----- From: "Alexander Chemeris" <Alexander.Chemeris at sipez.com> To: "Vincent Burel" <vincent.burel at vb-audio.com> Cc: "Conrad Parker" <conrad at metadecks.org>; <speex-dev at xiph.org>; "Jean-Marc Valin" <jean-marc.valin at usherbrooke.ca> Sent: Thursday, November 13, 2008 11:31 PM Subject: Re:

Hello, To start with, thanks a lot for making such a great voice codec available! Having recently upgrading to speex rc1, It occurred to us that there seems to have been a regression in the quality of encoding since version beta1. We are compressing some 22khz wave files in wb mode with maximum quality / complexity in VBR, and the result was really great with speex beta1. With rc1 (or beta3),

> Oh, you're right, inband handling is different, but it's a matter of one > flag, passed to functioin. Probably not that much to keep code DRY. Well, let's first merge your code and then we'll see about possible simplifications. >> frame: 20 ms encoding >> sub-frame: 5 ms encoding (internal) >> layer: one frame of nb or sb >> sb: sub-band >>