Discussion:
[Freetel-codec2] Thoughts
Brian Bartholomew
2016-09-07 21:32:46 UTC
Permalink
What alterations would it take for this codebase to be adopted in a
bunch of commercial products in the same way as BSD Unix and Linux?

I believe new research and signal processing coding can only be done
by experts. I also believe more new implementations and ports will be
done by non-experts, if the time investment before the first visible
success by the new developer is lowered. Is there disagreement on
this point, or just about how to make it happen?

Perhaps the project can collect donations to hire a interested student
to be a part-time librarian. Pay someone who already wants to learn
this codebase just enough to do this instead of some other part-time job.

Brian

------------------------------------------------------------------------------
Bruce Perens
2016-09-07 18:16:24 UTC
Permalink
David does code in an older style and that can look odd to newer
programmers, but the newer styles look verbose to older programmers. I tend
to use every const declaration possible, etc., so that the compiler will
show me more coding errors and it has frustrated me that the codec2 code
doesn't do the same, but I'm sure the verbosity would drive some people
crazy. Newer code uses something like Doxygen to self-document, which would
be a good project to add.

Regarding how open the church is, when you do close-to-the-metal coding,
real-time, or have to handle timing and latency issues, you need a greater
skill level. And in general I'd expect anyone to approach a project of any
level to have a really good look at the way things work before approaching
the developers. I can't overstress the importance of reading other
programer's code in the Open Source community.

I am in the unenviable position of having to clean up after commercial
programmers who code for consumer and B-to-B products, usually when they
infringe copyright and I have to help them to remedy the infringement.
These are companies like LG and Google, and vendors to banks, Wall Street,
and government. We can't pretend their standards are higher. The most
glaring lack is regarding security - most folks just haven't spent enough
time in the shoes of an operating system programmer to understand it. But
this also comes out in the way they deal with any systems programming issue.
glen english
2016-09-14 01:30:45 UTC
Permalink
Hi
I am now porting into a cortex M7, as we speak

wading through all the codec 2 sources, which I have only ever browsed
the encode and decode files

I see the src folder has pretty much everything in it.....
and I just want a bit of it...

is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv

etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?

or " am I doing it wrong " ?

73

glen





------------------------------------------------------------------------------
David Rowe
2016-09-14 01:53:05 UTC
Permalink
Hi Glen,

Like a lot of open source, it's evolved organically over many years.

If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead code)
... I'm happy for them to have a go.

You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.

Cheers,

David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever browsed
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
glen english
2016-09-14 01:57:43 UTC
Permalink
yes, codec2 core. I'll have a look at he files built for codec2 testing
etc- they'll be the ones I want.

thanks David
Post by David Rowe
Hi Glen,
Like a lot of open source, it's evolved organically over many years.
If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead code)
... I'm happy for them to have a go.
You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.
Cheers,
David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever browsed
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Bruce Perens
2016-09-14 03:23:40 UTC
Permalink
If you want to re-organize directories, please first learn the interesting
method that CMake has to deal with CMakefiles in subdirectories. It's not
bad, just not what you might expect if you're used to straight Makefiles.

Thanks

Bruce
Post by glen english
yes, codec2 core. I'll have a look at he files built for codec2 testing
etc- they'll be the ones I want.
thanks David
Post by David Rowe
Hi Glen,
Like a lot of open source, it's evolved organically over many years.
If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead code)
... I'm happy for them to have a go.
You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.
Cheers,
David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever
browsed
Post by David Rowe
Post by glen english
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------
------------------
Post by David Rowe
Post by glen english
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
Post by David Rowe
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-09-14 06:12:48 UTC
Permalink
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);
Post by David Rowe
Hi Glen,
Like a lot of open source, it's evolved organically over many years.
If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead code)
... I'm happy for them to have a go.
You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.
Cheers,
David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever browsed
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Brady O'Brien
2016-09-14 06:24:17 UTC
Permalink
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
Post by glen english
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);
Post by David Rowe
Hi Glen,
Like a lot of open source, it's evolved organically over many years.
If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead code)
... I'm happy for them to have a go.
You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.
Cheers,
David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever
browsed
Post by David Rowe
Post by glen english
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------
------------------
Post by David Rowe
Post by glen english
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
Post by David Rowe
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Brady O'Brien
2016-09-14 06:25:41 UTC
Permalink
Oh, no, I misread that. The return types are correct. They're still in
pack.c.

73
Post by David Rowe
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
Post by glen english
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);
Post by David Rowe
Hi Glen,
Like a lot of open source, it's evolved organically over many years.
If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead code)
... I'm happy for them to have a go.
You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.
Cheers,
David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever
browsed
Post by David Rowe
Post by glen english
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------
------------------
Post by David Rowe
Post by glen english
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
Post by David Rowe
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-09-14 06:31:25 UTC
Permalink
------------------------------------------------------------------------------
Brady O'Brien
2016-09-14 06:34:57 UTC
Permalink
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.
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
Oh, no, I misread that. The return types are correct. They're still in
pack.c.
73
Post by David Rowe
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
Post by glen english
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);
Post by David Rowe
Hi Glen,
Like a lot of open source, it's evolved organically over many years.
If a re-org was to happen - the big question is who will take
responsibility for it. If some one really wants to re-organise things,
and is willing to carefully ensure nothing is broken (x86, Octave,
embedded targets, Makefiles, unit tests, sort through/archive dead
code)
Post by David Rowe
... I'm happy for them to have a go.
You didn't mention which part you wanted? If it's the files reqd for
FreeDV 1600 on an embedded platform, take a look in
codec2-dev/stm/Makefile at the variable CODEC2_SRCS and SM1000_SRCS for
what we use for the SM1000.
Cheers,
David
Post by glen english
Hi
I am now porting into a cortex M7, as we speak
wading through all the codec 2 sources, which I have only ever
browsed
Post by David Rowe
Post by glen english
the encode and decode files
I see the src folder has pretty much everything in it.....
and I just want a bit of it...
is there any reason for everything in one folder?
rather than
/demos
/tests
/codec2_core
/fmdv
etc ?
would save me going through each file looking for dependencies.
or is there a list somewhere ?
or " am I doing it wrong " ?
73
glen
------------------------------------------------------------
------------------
Post by David Rowe
Post by glen english
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
Post by David Rowe
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------
------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
------------------------------------------------------------
------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-09-14 06:39:04 UTC
Permalink
------------------------------------------------------------------------------
Brady O'Brien
2016-09-14 06:42:03 UTC
Permalink
I sent it directly, as the mailer daemon has *.zip blacklisted
super!
mel_cb
lspmelcq_cb
lspmelvq_cb
codebookmel.c
codebooklspmelvq.c
maybe just send me all the codebooks and I will overwrite and DIFF
anything I already have
cheers
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.
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
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 <
Post by David Rowe
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
Post by glen english
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
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-09-14 06:56:55 UTC
Permalink
thanks Brady

Just dealing with the mallocs and I'll be rolling
builds fine. I'll have some cycle counts on the M7 shortly.

pretty good source people - well done. only took about hour getting it
into my enviro...

time to pick up the kids . already late. you know how software is...
just one more compile.

cheers
Post by Brady O'Brien
I sent it directly, as the mailer daemon has *.zip blacklisted
------------------------------------------------------------------------------
glen english
2016-09-14 13:41:37 UTC
Permalink
------------------------------------------------------------------------------
Bruce Perens
2016-09-14 19:14:57 UTC
Permalink
and OK now this is totally untouched code apart from removing all the
mallocs

Please mind that the code remains re-entrant.

Thanks

Bruce
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...
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
I sent it directly, as the mailer daemon has *.zip blacklisted
super!
mel_cb
lspmelcq_cb
lspmelvq_cb
codebookmel.c
codebooklspmelvq.c
maybe just send me all the codebooks and I will overwrite and DIFF
anything I already have
cheers
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.
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
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 <
Post by David Rowe
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
Post by glen english
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
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
------------------------------------------------------------
------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-09-14 22:53:28 UTC
Permalink
------------------------------------------------------------------------------
glen english
2016-09-15 13:41:05 UTC
Permalink
got home from tradeshow 9pm, 11:30pm now some results....

- Changed over to using CMSIS optimized FFT library
- fixed stack size issues (golly it is hungry)

NO other optimization , just changed out the FFT, so far

Results

codec2 3200, 20mS frame (size of the process)., Pclock = 168e6
-O0
encoder : 1.55e6, (9.28mS)
decode : 1.057e6 (6.29mS)
IE fullduplex and time to spare

-O2
encoder : 435e3 (2.59mS)
decode : 671e3 (3.99mS)

have not looked into why the decode was "hard" to optimise. that mght
take some time

or, could be an indication of something amiss.

I reckon, dealing with a few other things, there is another 2:1
improvement to get

There are some things I have not checked for compatibility with
kiss-fft- like the output sample order - natural or reversed etc. I can
produce in either natural or BR. ..
but I know it is actually doing the ffts. they take about .

total time spent so far- 4 hours. not bad result.

Nice work David, by my standards, this is not a trivial signal
processing application you have....rather alot to it....impressive.

bedtime..



------------------------------------------------------------------------------
glen english
2016-09-15 13:50:40 UTC
Permalink
post script

those encoder numbers look too good to be true, I suspect the optimizer
is stripping something out.

but it is the same codebase 100% (except for FFTs)..and we're using the
same GCC compiler, and FFTs are getting executed, so... well it needs
more time.

Not sure about same compiler and linker flags and options, I'll need to
find those.

I'll need to run some test vectors through it :-)

cheers all





------------------------------------------------------------------------------
glen english
2016-09-15 21:51:31 UTC
Permalink
All : Has anyone got any rough numbers on codec2 perf on the Sm1000
stm32f4 style platform ?

David : do you have any feel for how much precision in the FFTs is(are)
enough ?
A guess is fine. Your guesses are better than most people's facts.





------------------------------------------------------------------------------
David Rowe
2016-09-15 23:14:53 UTC
Permalink
Hello Glen,

I haven't measured codec 2 enc/dec alone on the STM32F4 for some time.
On the SM1000 it's the complete FreeDV 1600 stack we tend to measure
(modem, protocol, codec).

Danilo from the mcHF team recently reported 17.3ms for Codec 2 1600
decode on 40ms frames. IIRC the encoder uses less. I'd expect 3200 to
be a fraction higher as it's doing bit unpacking, LSP decoding more
often, but still run full duplex comfortably in real time.

I used codec2-dev/stm/codec2_profile.c to profile the code when I
initially ported to real time. This could be modified to run 3200.

If you are interested in pushing any of your changes into codec2 SVN,
they need to be verified against the current code base, for example
shown to be bit exact or withing a small tolerance of the current code.
Let me know if you want to work on this testing. Danilo and the mcHF
worked with me on this approach with fantastic results.

Changing FFT sizes would lead to output that is very hard to verify, so
I don't recommend it if you goal is code optimisation.

-/-

One change I'm discussing with the mCHF guys is using a real input N/2
size FFT rather than the current complex N point FFT. That would help a
lot and would be close to bit exact. If anyone is interested in working
on that please let me know - it can be developed on an x86.

When I originally ported codec 2 to the STM32 platform 3 years ago I
didn't find any significant improvements using the STM library FFTs (see
codec2-dev/src/fft_test.c). IIRC another guy tried them again a few
months ago, with just a slight improvement. I think he posted his
results to this mailing list.

If you can send me a fft_test.c style unit test that runs on a Discovery
and demonstrates significant improvements over kiss_fft I'd be happy to
try it.

Cheers,

David
Post by glen english
All : Has anyone got any rough numbers on codec2 perf on the Sm1000
stm32f4 style platform ?
David : do you have any feel for how much precision in the FFTs is(are)
enough ?
A guess is fine. Your guesses are better than most people's facts.
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
glen english
2016-09-15 23:25:12 UTC
Permalink
Hi David
thanks for your time to write and points,

Daniele : 17.3mS for a decode 40mS is good.

On FFT precision- I meant the FFT output data- how many significant
digits? I gather not many.
There are some shortcuts if you dont need full float precision mantissa.
But, given the hand coded assembled FFT on the device isvery hard to
beat, I think just leaving it as it is would suffice.

Agreed on implementation verification.

Looking at the code, there's probably an easy 2:1 improvement without
much work, but only worthwhile if we needed get it I think. The branch
predictor / dual issue on the M7 helps a ton for general purpose code.

Which Discovery have you got ?

g
Post by David Rowe
Hello Glen,
I haven't measured codec 2 enc/dec alone on the STM32F4 for some time.
On the SM1000 it's the complete FreeDV 1600 stack we tend to measure
(modem, protocol, codec).
Danilo from the mcHF team recently reported 17.3ms for Codec 2 1600
decode on 40ms frames. IIRC the encoder uses less. I'd expect 3200 to
be a fraction higher as it's doing bit unpacking, LSP decoding more
often, but still run full duplex comfortably in real time.
I used codec2-dev/stm/codec2_profile.c to profile the code when I
initially ported to real time. This could be modified to run 3200.
If you are interested in pushing any of your changes into codec2 SVN,
they need to be verified against the current code base, for example
shown to be bit exact or withing a small tolerance of the current code.
Let me know if you want to work on this testing. Danilo and the mcHF
worked with me on this approach with fantastic results.
Changing FFT sizes would lead to output that is very hard to verify, so
I don't recommend it if you goal is code optimisation.
-/-
One change I'm discussing with the mCHF guys is using a real input N/2
size FFT rather than the current complex N point FFT. That would help a
lot and would be close to bit exact. If anyone is interested in working
on that please let me know - it can be developed on an x86.
When I originally ported codec 2 to the STM32 platform 3 years ago I
didn't find any significant improvements using the STM library FFTs (see
codec2-dev/src/fft_test.c). IIRC another guy tried them again a few
months ago, with just a slight improvement. I think he posted his
results to this mailing list.
If you can send me a fft_test.c style unit test that runs on a Discovery
and demonstrates significant improvements over kiss_fft I'd be happy to
try it.
Cheers,
David
Post by glen english
All : Has anyone got any rough numbers on codec2 perf on the Sm1000
stm32f4 style platform ?
David : do you have any feel for how much precision in the FFTs is(are)
enough ?
A guess is fine. Your guesses are better than most people's facts.
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
glen english
2016-09-16 01:03:12 UTC
Permalink
-O2

forward FFT, 512 complex

kiss_fft 70,100 cycles (C )

CMSIS : 31,700 cycles (assembler)

had not compared cache impacts.

g




------------------------------------------------------------------------------
Steve
2016-09-14 19:42:35 UTC
Permalink
I think the only two modes used anymore are 700B and 1300. At least,
those two are the ones with modems.

------------------------------------------------------------------------------
Loading...