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 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
