[Discuss-gnuradio] volk kernels and num_bytes vs num_points

[Josh Blum]

Hey VOLK enthusiasts,

It looks like in just a few kernels we use num_bytes as the length
parameter rather than num_points. I think this may have been a source of
confusion and perhaps a few test failures.

See, we pass random number of points into these kernels for test. But,
when random numbers of points were interpreted as bytes, you get caught
slicing points/items down the middle... I found this out the hard way
when doing some alignment work.

I have pushed a branch that fixes 12 kernels that do this. I hope we can
merge this into the "next" branch. Since, I suppose its an API change.
Or we call it a fix and merge it into maint/master. Anyways...

It looks like the only code affected is in gr-filter. I suggest Tom take
a second look at the usage of volk_32fc_x2_dot_prod_32fc. Whether or not
we take the changeset, it might be good to verify that the following
code isnt being bitten by this usage:

> ./gr-filter/lib/fir_filter.cc:        volk_32fc_x2_dot_prod_32fc_a(d_output, 
> ar,
> ./gr-filter/lib/fir_filter_with_buffer.cc:    
> volk_32fc_x2_dot_prod_32fc_a(d_output, ar,
> ./gr-filter/lib/fir_filter_with_buffer.cc:    
> volk_32fc_x2_dot_prod_32fc_a(d_output, ar,


And here is the commit for reference:
http://gnuradio.org/cgit/jblum.git/commit/?h=volk_next_use_num_points

-josh