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.
