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
