Yes it is, But input is always double:( BR Nikos
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
