Nice:)
On Sat, Jul 9, 2022 at 6:33 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > > 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 _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
