Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Tom,


(inline comments)


On 30-07-13 15:53, Tom Rondeau wrote:
> The codec2 needs a bit of attention. I've not known it to fail like 
> this (and that's a very close result you're seeing), but we need to 
> update the version of codec2 that we're using. So unless you really 
> wanted to use codec2 with GNU Radio, just ignore this error since it's 
> very isolated.
> > But I must say that there does is quite a difference between the test in
> > gnuradio 3.6.4.1. and 3.7.0
> >
> > All the stuff about "data" and "expected data" are simply not present in the
> > test-script in 3.6.4.1.
> >
> > Perhaps the thing here is that the script for 3.6.4.1. simply does not do
> > this "compair with what we expect" test and it might be that this codec2
> > library is just as wrong on 3.6.4.1 as in 3.7.0
> Apparently, in 3.6, we weren't actually properly testing that code.

Some time ago, there was a discussion in the mailing-list about exactly 
this, about the effects of code-optimalisation.

It turns out that when you start really optimizing code for specific 
processors or specific features (like Single-instruction-multiple-data) 
it is very difficult to do so without effecting the outcome of the 
codec2 decoding process.

I'm not an expert on ARM code optimalisation but it seams to be that the 
way floats are processed will under certain conditions result in very 
small differences in the result when you decode a codec2 frame to a PCM 
frame.
The difference are very small (after all, you do not hear a difference 
of 1 or 2 over a 65536 scale of 16 PCM audio) but they are there!
This was also seen when running the codec2 code on (say) a PPC processor 
instead of a intel or a ARM.



Now, I'm not a expert in the low-level code of the codec2 libraries or 
on volk, but I think it may be we are seeing the same thing here: that 
the code-optimalisation operations in volk result in these small 
differences -depending on what processor the code runs on- which is what 
causes this particular test to fail in the GNUradio 3.7.0 "make test" 
script.

So it might be that it would be better to remove these bit-comparison 
tests again as it will probably confuse people. People do expect a "make 
test" to result in a 100 % success-rate.


> Tom
Chéééééério!
Kr. Bonne.