On 2022-07-09 11:02, Nikos Balkanas wrote:
Correction> These functions work on integers.
So they go as:
int16 data = htobe16(le32toh(int32 data))
Or the associate functions,
htonl, htons
So you need to already have converted your floats to ints...
If in doubt, test them first on a single data...
Sorry about the confusion.
Nikos
My question would be--why?
UHD and Gnu Radio already do these conversions for you.
The *single* case where being able to send sample data as big-endian
SC16 without any intervening conversions is from a file. Anything that
involves computation-with-samples
on the host requires, necessarily, that those samples be in a format
understood by the CPU on the host.
Further, if there are bottlenecks, I would want to absolutely confirm
that the major bottleneck in the UHD driver is in doing conversion to
big-endian wire format before
venturing down the road of making that available "directly". I
have lost track of this thread, but my recollection is that this file
originates in a capture from a HackRF
whose absolute-maximum sample-rate is 20e6SPS. That's a rate that
is *easily* handled by the existing UHD "stack" without resorting to
this type of optimization, IMHO.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
