You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After working a lot with Boost.Asio, when they abstract something, they still give access to the native element underneath (see here), and it seems SoapySDR does not provide this access.
Many times I'm faced with an incomplete Soapy driver for an SDR where not all the necessary calls have been fully implemented (see pothosware/SoapyBladeRF#36). Having access to the underlying native handle would allow me to not be stuck and to make the library calls myself. It would also allow to go beyond what the SoapySDR API can provide, since for example, it allows to set a clock reference but not its frequency.
Something as simple as:
void* getNativeHandle(void) const;
Where each driver could, if they so desire, return the appropriate handle to the device.
I understand if you do it for the device, you should do it for the stream, and some drivers might be using more than one object. I'm not aware of all the variations, but I still think it would be useful in some situations to have access to this.
The text was updated successfully, but these errors were encountered:
After working a lot with Boost.Asio, when they abstract something, they still give access to the native element underneath (see here), and it seems SoapySDR does not provide this access.
Many times I'm faced with an incomplete Soapy driver for an SDR where not all the necessary calls have been fully implemented (see pothosware/SoapyBladeRF#36). Having access to the underlying native handle would allow me to not be stuck and to make the library calls myself. It would also allow to go beyond what the SoapySDR API can provide, since for example, it allows to set a clock reference but not its frequency.
Something as simple as:
Where each driver could, if they so desire, return the appropriate handle to the device.
I understand if you do it for the device, you should do it for the stream, and some drivers might be using more than one object. I'm not aware of all the variations, but I still think it would be useful in some situations to have access to this.
The text was updated successfully, but these errors were encountered: