similar to: strange encode/decode results on C54x

Hello, I currently have speex "working" in my project but the encode and the decode don't seem to be working like I would hope. I am using speex 1.2beta2 and I am trying to 16bit 8kbs narrowband. on the decode side I encoded a voice on a windows machine. I took the encoded information and transferred it over to the C54x project and decoded it and it didn't sound that great.

Michael Jacobson a ?crit : > wow, the attitude wasn't necessary. Sorry about that, but I also like when people read the doc carefully. > What I was asking wasn't in the > documentation, how am I supposed to know I wasn't supposed to initialize > the encoder/decoder every time (I was trying to save space for the > allocs), I've never dealt with codecs before and

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

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

John, > I can see that there has been some effort to compile the SPEEX codec to operate on the > TI c54x and c55x DSPs and I am wondering if anyone would be able to update the > mailing list with their current MIPs and Memory resource requirements for their c54x > and/or c55x compilation? The only estimate I was able to find in the mailing list archive > was 42MIPs but I'm

Hi, I can see that there has been some effort to compile the SPEEX codec to operate on the TI c54x and c55x DSPs and I am wondering if anyone would be able to update the mailing list with their current MIPs and Memory resource requirements for their c54x and/or c55x compilation? The only estimate I was able to find in the mailing list archive was 42MIPs but I'm not sure if this is an

Jean-Marc, I have attached a small patch with modifications to arch.h, bits.c, and misc.c. This contains the few mods remaining to support the various fixed point TI DSPs after the work that you did at the end of May (thank you for this). arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x and older C64x does not) bits.c: Allow external definition for max

Hi Jim, Thank for the patch. I'll apply it when I have a few minutes. If I haven't done so after a few weeks, please send it again. I'm in the process of relocating to Australia, so everything's a bit of a mess around here. Also, please post the c5X-specific files to the list (.cmd, .pjt, ...) so they'll be archived. Last thing, I see you defined spx_word64_t as long long for

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already

The attached file contains build files for TI's Code Composer Studio (CCS) for the C54x, C55x, and C6x DSPs. I had intended to post this a couple of months ago, but it took a long time to get around to doing the little bit of cleanup required. This is a file I/O loopback application suitable for running with the CCS simulators, for evaluating memory and MIPs requirements for these

This is going to take some explaining and I apologize in advance if any of this is found in the manual or sample code but I couldn't find it. I just graduated last may and this is my first experience with vocoders and dissecting a professional's code. I work for a company that is currently using a G729A vocoder from a 3rd party software company and is looking into speex so they no

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.

Jean-Marc, Here are the patches, broken out one per file. I did some additional work in the testenc files based on Peter Mlakar's post to make it easier (though still a bit klunky) to try different rates. These changes also incorporate the file window.c into the builds, change the decoder startup delay to account for the change in the algorithm delay from 10ms to 5ms, and change bits.c

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

Jim Crichton, I'm trying to run speex on omap 1610 platform and i saw that you have a patch for c55. When i saw your mail about this, i decided to ask you for send me those files above: include\config.h (not automatically generated, sets memory sizes, enables manual alloc) include\speex\speex_config_types.h (match Speex types to compiler types, not generated from types.in

Jean-Marc, >> Build 11169 in SVN works correctly. > > Good. I'll try not to forget the EXTEND32 from now on. > >> I have attached a zip file (renamed >> .txt) with a patch to bits.c to make the byteswapping for TI DSPs >> consistent. > > Seems like unzip can't read it. Either it's in an unknown format or the > file got corrupted. Could simply

Hi list! There seem to be some oddities in using ABR. The first thing I notice is that because "abr_count" increases without bound, after a while the weight of the bitrate history will completely swamp any change in the current bitrate and the ABR adjustment will essentially stop happening. This seems to be true in any mode (not just UWB) and perhaps a solution is to cap

On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrj?l? wrote: > On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > > On 25.02.2020 12:21, Ville Syrj?l? wrote: > > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > > >> On 19.02.2020 21:35, Ville Syrjala wrote: > > >>> From: Ville Syrj?l? <ville.syrjala at

>> Nice call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your