Re: Releases v3.8.4.0 and v3.9.3.0

On 2021-10-01 11:46 a.m., Franco VENTURI wrote:
> 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
>
>
This is a generic problem not just restricted to SDRPlay.  UHD devices
have functionalities that aren't fully-captured by either of the
abstraction libraries (gr-osmosdr or
  SoapySDR).  But still probably 90% of my applications can still use
the generic abstractions, even with UHD devices.

My own position is that folks writing flow-graphs should try to be
abstracted from the hardware as much as possible.  That isn't always
possible.