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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
