Hi Sebastien
I agree with your spirit and comment. I agree the current codebase can
be a little difficult to follow !
I think the requirement and definition of "reference C code" requires
that there is no optimisation, and no machine specific instructions , no
unrelated or unused code etc. Is this your driving point ?
regards
glen english
On 14/12/2023 8:41 pm, Sebastien F4GRX wrote:
Hello,
I agree reference code is important as a known-good base to help test
the compliance of third party implementations, but code NEVER has been
equivalent to a specification.
Code is usually complex, and specific to a particular kind of
machines. it uses shortcuts, optimizations, and is linked to its
implementation language. it's almost art. It is unusable to build a
hardware version of the codec. So, it's not a spec.
A formal spec is more important, as it describes the pure algorithmic
structure of the codec in a concise, synthetic, yet practical way.
Writing a spec is a also a way to make sure we know what the code is
doing, without having to know how to code. And to make sure no detail
is left out.
For example, there is a difference between writing "energy is
quantified linearly by selecting codes in this lookup tables for these
values of energies" and having to browse dozens of files to find which
encoding table and routine are used for a specific mode.
I know because was there before, I tried as a third party developer,
to document codec2 algorithms from code, without previous intimate
knowledge of the algorithms (I have already shared my doc).
I found it very difficult to do, not because codec2 is complex, but
because the current codec2 code base is quite large, comes with lots
of unused and/or unrelated routines, and as such is very hard to
follow. This is normal.
I am very glad that a specification is finally available. I have not
yet been able to read it yet as github told me the pdf was corrupted,
but I hope to get it soon, read it, help improve it, and use it to
finally build a fixed point version.
Thank you very much for this document,
Sebastien
Le 13/12/2023 à 23:35, glen english LIST a écrit :
I support reference C code
For a developer who needs to implement an algorthm on their platform,
the reference C code (RCC) provides ability to numerically test
bench their platform code (essential) , and provides a well broken
down algorithm method in the form of C code (essential) .
In my opinion, an implementation developer does not need to
understand how and why , just what has to be done.
I'm starting to implement Codec2 on a RISC-V soft micro on an FPGA
with custom instructions. I started with the RCC, and identify
regions that I can generate FPGA acceleration in the fabric , and I
test bench it against vectors produced by the RCC.
(While I have a general interest in the inner workings) - I don't
need understand David's excellent Codec2 math inclusive
documentation, I just need to implement my numerically accurate
version of the RCC
-glen VK1XX
On 14/12/2023 9:24 am, david wrote:
Hi Greg,
Thanks for your comments, good to get a perspective from a non DSP
person. Some thoughts:
1/ The modes are not interoperable.
2/ The "stable" question is a good one. I consider codec2 unstable, as
I am dissatisfied with performance and enjoy experimenting. Having
said that, the youngest mode is now 7 years old, and some haven't
changed in a decade. I don't think we'd remove any existing modes that
had a user base > 1.
_______________________________________________
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
