Native format allowing buffer optimization?

[xloem]

SoapyRTLSDR tells Soapy its native format is CS8, but it looks like the actual native format is CU8.

The code simply subtracts 127 from all values. If it specified CU8 instead, could it simply forward the data without having to process it?

See https://github.com/pothosware/SoapyRTLSDR/blob/master/Streaming.cpp#L379

[cjcliffe]

That's a fairly simple fix and makes sense; I'll add CU8 and make it the native default.

[guruofquality]

A few things to keep in mind.

• The native stream format is what soapy remote uses over the wire. So we are going to have to add another conversion to soapy remote for this change (otherwise it will fall-back to floats). And readStream() will need to support CU8 as well.
• Worth mentioning too; the direct buffer access api is currently operating on the native "CU8" samples, but the readStream() call actually provides CS8 format.

Its not so bad to add CU8 to soapy rtl, and soapy remote could always support more format conversions.

[cjcliffe]

Would it be a stretch to handle the same format conversions for local devices in SoapySDR? It would be nice if I could request CF32 even if a module only supplied something like CS16 or CS8. Seems convenient for remote but I have to handle potentially all of them in-app for local devices depending on what is or isn't implemented in the module..

[guruofquality]

Would it be a stretch to handle the same format conversions for local devices in SoapySDR?

Yea, its crossed my mind a few times. If SoapySDR had a common library of conversions, it could be used by the remote, and any local module. Without interfering too much with the ability to customise the read/write stream calls. I think maybe some new SoapySDR API calls to:

• given a native format, get a list of source formats that we can convert from
• given a native format, get a list of target formats that we can convert to
• given a source format and destination format, get a pointer to the conversion function

[guruofquality]

In any case, I added SU8 to soapy remote: pothosware/SoapyRemote@8f6715c

[guruofquality]

Would it be a stretch to handle the same format conversions for local devices in SoapySDR?

Made a new issue for this: pothosware/SoapySDR#49

[zuckschwerdt]

Is anyone still working on this? I would offer to add CU8 support to SoapyRTLSDR. Just as supported format, not as "native" format, so existing consumers can continue to auto select CS8.