similar to: Precomputing the remaining floating pointoperations.

I see there are still some floating point operations left in the codec init(ialization) code. Changing that code to fixed point is not only difficult (due to the trigonometric functions etc) but may also degrade the precision. Here is an idea whereby we can easily precompute (record) all those values on a powerful processor and then use (replay) them on an embedded processor / DSP. The only

Hi Jean-Marc, Hi Jim, I have also seen some problems with the 1.1.8 release on the C55x. So far I have boiled down the issues to the following: 1) We need our own "fixed_xx.h" header file. I don't know why, and haven't had time to investigate, but there is a definite improvement when I use the attached fixed_c55x.h file which has turned all the maths into inline functions.

I am trying to implement a relatively high number of encoders (24/32) on a single DSP and would like to minimize the memory requirements. Has anyone optimized the persistent EncState memory allocation for multiple channels. The default C64x fixed point implementation allocates 5280 bytes of persistent memory per encoder. I'm willing to restrict my settings to complexity 1, quality 3. It

Hi all I have spent the last three days evaluating CELT on our supported platforms. I found a bug in quant_bands.c, that due to processor/compilation differences did not cause an issue on x86 platforms, but is a problem on the MIPS processor embedded devices. When decoding on the MIPS devices, there was a lot of noise added during the decoding, the noise is mainly in the 15 khz to 21 khz range.

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

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

Hi, all. I have two questions about wideband encoding. >From "testenc_wb.c"... 1) tmp=8; speex_encoder_ctl(st, SPEEX_SET_QUALITY, &tmp); tmp=3; speex_encoder_ctl(st, SPEEX_SET_HIGH_MODE, &tmp); tmp=6; speex_encoder_ctl(st, SPEEX_SET_LOW_MODE, &tmp); How to set high_mode and low_mode, if quality is set to '9'? When I set quality '9'

> Another issue is the memory allocations distributed so many places that > it's hard to provide a single memory initial function interface. > > In a VoIP case on ARM, the total memory size for speex codec should be > known at the inital stage since all the memories are allocated > at the initial stage. If you want everything in the same big block, all you need to do is

I'm glad to hear that my data size can be shrunk considerably, however I do not know the minimum values that I would set the static arrays to be. I hate to be a bother but could you tell me the minimum values for these arrays/structures in the state structure? Thanks! encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch

Hi, It is better to replace this line in function filterbank_new: max_mel = toBARK(EXTRACT16(MULT16_16_Q15(QCONST16(.5f,15),sampling))); to max_mel = toBARK(EXTRACT16(sampling/2)); It gives the same but it seems to be faster and avoids overflow on 44100 kHz that prevents denoiser to process 44100 streams. (Yes I know that Speex should not pack 44100 streams but it does now and I use it). Best

Hi everyone, As you may have guess, Speex 1.2 is slowly approaching, though there's still a lot left to do so I can't say how long it'll take. I thought this was the right time to ask if there's anything missing or that can be improved to make 1.2 better. At this point, it can't be anything major, but there are still some changes that are possible, e.g: - Improving some

I would like to make lpcSize a multiple of 4. In the current library for narrow band mode lpcSize is currently set to 10. I would like to increase this 12 for optimization reasons. Is it a simple matter of just changing lpcSize in the structures in mode.c or are there other implications to doing this? I did try and change the value but I seem to be getting some runtime errors indicating a

Okay, Not exactly the answer I was looking for. This sounds like a big change. I don't mind re-writing the LSP quantizer but re-training code books and breaking compatibility is not what I want to do. I am working on an optimization for an ARM cortex-A8. It is desirable to process things in 4 element blocks. Is there a simpler approach you could recommend? Vasant Shridhar

I've been browsing around the speex-1.10 source tree. Firstly I see 'float' is still used in many places. Can't we change them all to the appropriate type (spx_wordxx_t or similar) defined in arch.h ? Secondly I see there is a lot of duplication regarding real-valued constants. One way would be to say: #ifndef FIXED_POINT #define CONSTANT(x) (x) #else #define CONSTANT(x)

On 11-04-11 06:48 PM, Shridhar, Vasant wrote: > Okay, > > Not exactly the answer I was looking for. This sounds like a big > change. I don't mind re-writing the LSP quantizer but re-training > code books and breaking compatibility is not what I want to do. I am > working on an optimization for an ARM cortex-A8. It is desirable to > process things in 4 element blocks.

The results are at www.rational.co.za/speex.csv Each of the 11 quality settings is tested 3 times (narrow, wide and ultra wide band). Strangely narrow band quality 11 outperforms all wide band tests, but it can be due to my subsampling or some other inaudible effect like delaying. You can import it into Excel and sort it by SNR or other value. Divide the bits by 24 to get the bps. The

Hi, So I got a crash on the following code: k1=SUBMODE(lpc_enh_k1); k2=SUBMODE(lpc_enh_k2); which in the newer codebase is: bw_lpc(SUBMODE(lpc_enh_k1), st->interp_qlpc, awk1, st->lpcSize); bw_lpc(SUBMODE(lpc_enh_k2), st->interp_qlpc, awk2, st->lpcSize); I am not sure if the newer code will have the same issue but the following check is

>> I think the residual echo estimation is fairly reliable but I do not know >> how to use this to improve Pframe and in that way solve our main problem >> with the gain during near end talk. > > How can you tell that the residual echo estimation is reliable? in any > case, I suspect that the whole Pframe idea might have to be revised > (i.e. computing it completely

Hi I am currently trying to port speex v1.1.6 to a microcontroller with very limited memory (<64Kbyte RAM). what I found when initialising the encoder, a chunk of 32Kb was attempted to be alloced, which failed: src/nb_celp.c: void *nb_encoder_init(const SpeexMode *m) { /* snip */ st = (EncState*)speex_alloc(sizeof(EncState)+8000*sizeof(spx_sig_t)); /* snip */ } same goes for the

Hi, can someone help me understand and experiment with Speex in a better way than my knowledge. I want to change the LPC filter order of the Speex algorithm. I think I need to change the LPC order( or lpcSize) in modes.c file. but to make it work I need to modify the codebook also, can someone tell me how to go about changing the codebook entries to support the changed order of prediction.