Marcus, I understand your point, however when writing a generic module for SoapySDR like SoapySDRPlay you have to try to be "everything for everybody", and that sometimes leads to tradeoff and 'opinionated choices' you have to make in module.
For instance when writing the SoapySDRPlay module, I mostly used CubicSDR as my 'target' application, and in that case we had to make several choices (see for instance this thread: https://github.com/pothosware/SoapySDRPlay2/issues/62), which are well summarized in this sentence by Vincent Sonnier, one of the developers of CubicSDR (https://github.com/pothosware/SoapySDRPlay2/issues/62#issuecomment-571432329): I suppose that if we want to plug the square of RSP into the round of a Soapy module, we must cut corners eventually. On the other hand, when I wrote the gr-sdrplay3 GNU Radio OOT module, I worked on the assumption of a more advanced user that wants to have full control of the capabilities of these RSP SDRs, while choosing sensible defaults that would still allow anyone familiar with GRC to use them in their flowgraphs easily. Franco > On 10/01/2021 9:58 AM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > > > On 2021-10-01 7:34 a.m., Franco VENTURI wrote: > > If you are running GNU Radio >= 3.9, there's also the native SDRplay module > > I wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you can find > > the announcement to this mailing list here: > > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg00001.html > > > > Unfortunately it won't build on GNU Radio 3.8 because of SWIG. > > > > Since it interfaces to the native SDRplay API (version 3.X), it doesn't > > require SoapySDR or gr-osmocom; I haven't done any comparison with the > > other approaches of interfacing with the SDRplay RSP devices (SoapySDR and > > gr-osmocom), but if someone does, I would be really interested in hearing > > their results. > > > > Franco > > > > > My personal preference when writing applications is to make them > hardware-agnostic whenever possible, which is why I and am sure lots of > others > prefer the gr-osmosdr or gr-soapysdr approach of abstracting the > hardware interface. This is particularly important when the flow-graphs > you've > developed are going to be used by non-GR people, or even people who > have no particular expertise in modifying software.
