Re: Releases v3.8.4.0 and v3.9.3.0

[Franco VENTURI]

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 <patchvonbraun@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.