You are right. fftw says that in float precision, it accepts float inputs to the API. I assume they mean the libfftwf.so library and the fftwf_* API. I didn't specify precision in my build. So I got libfftw.so (as opposed to libfftwf.so or libfftwl.so). This simplified Makefiles and source code:) I/O with fftw_complex is still 16 B. A quick and dirty test with libfftw3.so and complexf I/O resulted with memory corruption.
I'll have to investigate this better and use the libfftwf.so library and fftwf api, when I have more time. I will update this thread when I do:) Thx again, Nikos On Mon, May 12, 2025 at 6:10 AM Nikos Balkanas <nbalka...@gmail.com> wrote: > Thx.I will check it:) > > On Mon, May 12, 2025 at 5:53 AM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 11/05/2025 22:45, Nikos Balkanas wrote: >> >> Yes it is, But input is always double:( >> >> BR >> Nikos >> >> Nope. >> >> https://www.fftw.org/fftw3_doc/Precision.html >> >> The FFTW3F routines used in Gnu Radio take in single-precision (32-bit) >> and output single-precision (32-bit). In most CPUs, >> the 64-bit floating-point pathways are slower than 32-bit pathways, >> which is why FFTW3 has a version of the libraries that >> process single-precision floating-point exclusively. This has been >> true literally for at least two decades of FFTW3, since I >> started using and contributing to Gnu Radio in 2004. >> >> Anyway, it's entirely up to you, but there's really no reason to use >> double-precision floats to process data that on the >> wire are only 16 bits. >> >> >> >> On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech <patchvonbr...@gmail.com> >> wrote: >> >>> On 11/05/2025 22:27, Nikos Balkanas wrote: >>> >>> Thx Marcus, >>> >>> I worked it out 2 days ago. Just my memory allocation. >>> I am passing input buffer with a global pointer. >>> I was using global stack allocation. When I switched to >>> malloc, it just works fine:) >>> Here is what happened: Input buffs didn't reach the _recv_one_packet() >>> where >>> b was evaluated to nil and therefore out_buffs were allocated to nil. It >>> would be helpful >>> to check allocations like these and issue a warning. >>> Input, however, still reached the convert_chdr_1_to_fc64_1_guts but >>> outputs and therefore output were evaluated to NULL. >>> With NULL output it was sent through the guts function. >>> Even commenting out the switch and sending it through >>> the generic chdr_sc16_to_xx crashed it with no output buffers:( >>> I am not quite sure why b is not evaluated in _recv_one_packet() >>> and is available downstream in convert_chdr_1_to_fc64_1_guts >>> with a global stack allocation. Unstable code? >>> >>> Anyway, I need the complex double for libfftw3. Its >>> input data is (fftw_complex) aka 16 B, no matter >>> what precision I use. It comes out in float, long double >>> and quad flavors, but input is the same. >>> And it blows Opencl fft I was using by 10x! >>> on the filesystem, less with live signals, >>> but still faster:) And signal power is hotter:) >>> >>> BR >>> Nikos >>> >>> FFTW3 is available in a single-precision instance -- Gnu Radio uses >>> it. FFTW3F. >>> >>> >>> >>> On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech <patchvonbr...@gmail.com> >>> wrote: >>> >>>> On 10/05/2025 07:17, Nikos Balkanas wrote: >>>> >>>> It turns out that the problem is not just bypassing the sse2 code:( >>>> After commenting it out, uhd still crashes. The conversion output >>>> buffers are not created in _recv_one_packet() >>>> Any ideas why they don't? >>>> >>>> TIA >>>> Nikos >>>> >>>> This should *Just work*. >>>> >>>> What happens if you use rx_samples_to_file and specify: >>>> >>>> --type double >>>> >>>> This should write out double-precision (64-bit) complex floats to the >>>> output file. You should be able to use that example >>>> code as a bit of a template. >>>> >>>> Also, I have to ask, why double precision? Even single-precision float >>>> has more precision and dynamic range than is >>>> actually represented by the 16-bit values on the wire, coming from >>>> the ADCs. By moving to double-precision, unless you >>>> have a library that only supports double-precision math, you're just >>>> slowing down your computations for no good reason. >>>> >>>> >>>> >>>> >>>> >>>> On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas <nbalka...@gmail.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I recently changed my host application to complex double. I had to >>>>> change my stream_args to >>>>> fc64. I pass my void pointer to uhd_rx_streamer_recv same as before: >>>>> ptr = (void **)&zin; >>>>> Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I >>>>> have only 1196 maxsamples, and crashes. I don't need the sse2 code for my >>>>> conversion. I only use 1024 complex >>>>> samples/packet for fft. I am very happy with the >>>>> generic chdr_sc16_to_xx. >>>>> Does anyone have any fc64 experience and how one can pass the void >>>>> buffer pointer to >>>>> skip the sse2 code? >>>>> >>>>> TIA >>>>> Nikos >>>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>> >>> >>> >>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
