[Freetel-codec2] M7 some numbers

[glen english]

OK, back from being at a meeting,and tracked down a unaligned access hardfault... golly kiss-fft chews up some ram eh....tsk tsk. and OK now this is totally untouched code apart from removing all the mallocs and there is alot of room for speedup... Cortex M7, @ 168 MHz code in flash, data in ram, no data or program in the TCM (yet) I and D cache ON, PRF, ART. doubles >> floats. 6 ws. Codec2-3200  (ie 2 x 10mS frames in a pass) encoding white noise. -O0, all debug turned on, loaded to the hilt. (debug build) encode - 2272197 cycles (13.5mS) (for 20mS frame) decode - 2049415 cycles (12.2 mS) try -O1 hmm crash. hardfault. time to go to bed. mem_fir in NLP writing over everything , probably due to corrupted access indices Will get back to this Friday Time to look at some of the build scripts to see what options  are set up for the compiler/linker glen On 14/09/2016 4:42 PM, Brady O'Brien wrote: I sent it directly, as the mailer daemon has *.zip blacklisted On Wed, Sep 14, 2016 at 1:39 AM, glen english <g...@cortexrf.com.au> wrote: super! yeah missing references to : mel_cb lspmelcq_cb lspmelvq_cb which belong in : codebookmel.c codebooklspmelvq.c maybe just send me all the codebooks and I will overwrite and DIFF anything I already have cheers On 14/09/2016 4:34 PM, Brady O'Brien wrote: Yes, I think the some or all of the codebooks are generated at compile time. I've got a copy of them sitting in my build directory if you'd rather not screw with it right now. On Wed, Sep 14, 2016 at 1:31 AM, glen english <g...@cortexrf.com.au> wrote: thanks very much  Brady also void then newline then pack that explains why find in files didnt find it need pack.h perhaps... I'll add that to my list. another question while you are still awake (!) what's the story with the codebook for the mel_cb  lsps  ( amongst a couple of others) ? the cmakefile refers to them like     COMMAND generate_codebook mel_cb ${CODEBOOKSMEL} > ${CMAKE_CURRENT_BINARY_DIR}/codebookmel.c is <codebookmel.c> generated (IE and not in source distro ) ? cheers On 14/09/2016 4:25 PM, Brady O'Brien wrote: Oh, no, I misread that. The return types are correct. They're still in pack.c. 73 On Wed, Sep 14, 2016 at 1:24 AM, Brady O'Brien <brady.obrien...@gmail.com> wrote: Hi Glen, They're under pack.c, as far as I can tell, although declared with different return types. There's something to add to the cleanup todo. 73 On Wed, Sep 14, 2016 at 1:12 AM, glen english <g...@cortexrf.com.au> wrote: OK, 15 minutes into it... where are: ????? they are declared in quantise.h but I cannot find any defition for them anywhere at all... with thanks void pack(unsigned char * bits, unsigned int *nbit, int index, unsigned int index_bits); void pack_natural_or_gray(unsigned char * bits, unsigned int *nbit, int index, unsigned int index_bits, unsigned int gray); int  unpack(const unsigned char * bits, unsigned int *nbit, unsigned int index_bits); int  unpack_natural_or_gray(const unsigned char * bits, unsigned int *nbit, unsigned int index_bits, unsigned int gray); ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2