On Mon, Jun 10, 2013 at 11:07 AM, <[email protected]> wrote:
>
> Small differences in the bit-exactness of floating point calculation are
> not errors. That's the problem...
One potential solution would be to use a software floating point library
while doing bit-exact verification of build system changes, algorithm
changes (such as trying a different FFT library), etc. Once those changes
were shown to be equivalent, the software floating point library could be
swapped out for whatever floating point method runs best on the hardware,
and it would seem reasonable (to me) to assume that the remaining small
differences in the floating point calculations would not be considered
errors. In other words, the codec2 "standard" would be defined using a
reference implementation with software floating point, and the optimized
implementations would be expected to vary slightly. For the sake of
verification, we might want to use a software floating point library that
is very high precision. It would not need to run real time on any
platform. It would need to return consistent results regardless of
compile-time options, and ideally on different hardware platforms.
I tried to take a step in that direction back in December. I hoped to use
a typedef for the floating point data type, with the intention of being
able to easily swap it out. The most simple case would be selecting
between "float" and "double". (I realize that calls to sin() and similar
would also need changed to sinf()... since they aren't overloaded). I also
wanted to compile the codec2 source as C++ so I could use a class with
overloaded operators for the floating point data type. I got stuck trying
to build the codec2 source as C++ when I couldn't find the source for the
autotools-generated files; maybe it would be easier now that cmake is an
option.
In my case, I wanted to use a C++ floating point library <
http://www.openexr.com/about.html> that represents floating point numbers
using only 16 bits, hoping it would run real time on a Blackfin DSP (which
doesn't have a FPU). Those using ARM targets without FPU could get the
same results using GCC's half-precision (16-bit) floating point __fp16 type
(currently supported only on ARM). I would expect that if the 16-bit
floats could handle the range needed for codec2 that they would work, but
that the audio quality would suffer somewhat from the limited resolution
(which might be acceptable or might not... I sure would like to try it).
Steve
--
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:[email protected]
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
