search for: speex_mode_queri

Hi there. I am having a little trouble understanding the frame sizes chosen by the codec. testenc_uwb.c from the speex-1.0 source distribution has a framesize of 640 hardcoded and makes use of this value exclusively. However, a mode query on the actual codec returns 320 as a framesize for this mode. int tmp; speex_mode_query(&speex_uwb_mode, SPEEX_MODE_FRAME_SIZE, &tmp);

Hello everyone, I'm finally beginning to use Speex for a project. As expected, the implementation so far has been very easy and I am thrilled with the capabilities and flexibility of Speex, especially the new features in 1.1. My efforts so far have resulted in a couple of questions: 1) I was interested in fetching the default quality setting for narrowband:

Hi Alexander, > Here is first attempt. I'm sending it here for review - am I understand > you correctly? If general approach is correct, I'll change code to use > modes from modes.c. I haven't tested, but it looks sane. Just a few comments: - printf("\tERROR not enough bits left after wb\n"); this is actually now an error. It just means you got to the end of the

Oops... You've just found a bug. Seems like you're the first one to use that call. Anyway, it's now fixed in CVS (both trunk and 1.0.x branch). Thanks for the bug report. Jean-Marc Le mar 03/06/2003 à 01:16, Christian Buchner a écrit : > Hi there. > > I am having a little trouble understanding the frame sizes chosen > by the codec. > > testenc_uwb.c from

> 1) I was interested in fetching the default quality setting > fornarrowband: > speex_encoder_ctl(_encodeState, SPEEX_GET_QUALITY, &value); > > Unfortunately, the above fails with libspeex 1.1.4. The console > shows: > > warning: Unknown nb_ctl request: 5 Actually, I never implemented SPEEX_GET_QUALITY. It's not that usefule anyway, but I might do it in the

> Use speex_mode_query with SPEEX_SUBMODE_BITS_PER_FRAME > You need to pass the submode number with the pointer and the number of > bits per frame is returned using the same pointer. Note that with > speex_mode_query, the first argument is the mode (e.g. &speex_nb_mode), > not the encoder/decoder state. Thank you Jean-Marc, This works well. Now a followup question. Is there

Hi, 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(). I've tested it with testenc in NB, WB and UWB modes with VBR enabled to test in as many cases as possible. It seems to work fine. Though,

This patch will export new speex functions in the generated library, such as speex_encode_int as well as the preprocessor, echo-cancellation and jitterbuffers. The ordinals used matches the 1.1.6 release from the speex.org website, so any new library created with this def file should be binary compatible with that one. -------------- next part -------------- Index: speex.def

> 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

Hi, when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o -lspeex_debug -lspeexdsp -lm

Jean-Marc was correct in that the 16bit value was the culprit for my encoding woes. after I changed that to a 32 bit value I believe it encodes correctly, but I really don't have much of any way to know this absolutely. I am using the 1.2beta2. I would use the enctest program, I have looked it over and based a lot of what I am doing on that code but the project I am developing this on is

Mike, Generally "Invalid mode encounterd" == "frames are misaligned" You should be getting 20 bytes from the encoder each time, and passing 20 bytes to the decoder each time. Is it correct that you have modeled your main loop after testenc-TI-c5x.c? If you look at encoded silence with a binary editor, you should be able to see the 20-byte repetition pattern. You can also

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

I thought I should be getting 20 words because in the windows app the command line repeats "nbBytes = 20" through the entire decode phase. I wonder how the frames got misaligned...right now I get 10 words of data followed by 10 words of 0's which I look at through a memory window in code composer. now I am pretty sure there is a terminator word that gets in there so that would make

Hi Jean-Marc, after some problems with getting svn to work here I finally made it. Problem is, you write that I cannot use libspeex and libspeexdsp at the same time now -- because I use a "live" system (mic-in -> speex_enc -> speex_dec -> headphone out) and I can run the AD1836 audio codec on 48 kHz only, I cannot use my program now (because I use speex resampling...) So I

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Jean-Marc, Frank, I have stumbled across a similar situation regarding optimization. I seem to have a similar setup as Frank does with a fixed 48khz in and out. The wideband mode and ultra-wideband modes are really what I?m looking for. I have a test application that reads audio, downsample to 16kHz (or 32kHz), speex encode, speex decode, upsample back to 48kHz, and playback. If I remove

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.