> and OK now this is totally untouched code apart from removing all the
mallocs

Please mind that the code remains re-entrant.

    Thanks

    Bruce

On Wed, Sep 14, 2016 at 6:41 AM, glen english <g...@cortexrf.com.au> wrote:

> 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>
>> 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>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>
>>>> 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 
> listFreetel-codec2@lists.sourceforge.nethttps://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

Reply via email to