packaging? and dealing with SDRPlay drivers
Closed this issue · 15 comments
So it looks like the SDRPlay drivers are a bit of a black-box with some registration required to get a hold of them. I'd like to figure out how I can use the drivers PPA and build support in the Pothos SDR environment. Things to figure out...
- Are they dynamic or static libraries?
- Can SDRPlay drivers be statically linked in to a client library?
- or if dynamic, redistributed with a binary installer?
- If we use dlopen and dlsym -- instead of linking, then the drivers can be a runtime dependency and not a build-time dependency. This solves the above issues by letting us build and package the SoapySDRPlay without the need of the SDRPlay drivers. It will be up to the end user to install the SDRPlay drivers to a well-known location. In addition, this is the only way we can have SDRPlay built for the ubuntu PPA -- because there wont be a source package for the SDRPlay drivers.
From what I can tell SDRPlay only offers the mir_sdr drivers in dynamic library format; so for now I'm guessing it will be up to the user to install the driver (it requires filling out a web form anyways) but we could let them provide the SoapySDRPlay binary packages on their site if it's in-demand.
@SDRplay may be able to help us figure out the best option here.
@cjcliffe We can certainly host binary packages of SoapySDRplay if that is ok with you. I'll email you directly to discuss.
@SDRplay that sounds good; I'll keep an eye on my e-mail and we can work it out there -- still a fair bit of optimizing to do on my end so I'm not in a rush to get anything out the door quite yet :)
@SDRplay There's a lot of options here. I was thinking that SoapySDRPlay is ready, I can build it into my windows installer (https://github.com/pothosware/PothosSDR/wiki).
The installer will distribute SoapySDRPlay support modules, but not the SDRPlay library. SDRPlay owners will have to download the driver separately and copy the dll somewhere into the %PATH%.
Anyway, just a thought. Let me know -- http://pothosware.com/#contact
I'd be glad to see if you can bundle it up as it seems to be functional -- I may have some important bug fixes and tweaks in the next week or so when the SDRPlay unit arrives but until then it would be great to have the installer available to download along with my CubicSDR-soapysdr-support test builds.
SDRPlay test unit arrived today; should now be able to get any remaining issues cleaned up and optimized 👍
Already getting results -- I wouldn't push this to binary yet.. I've definitely messed up the input filter bandwidth routine :D Will have it fixed shortly.
No problem. I still need to get a hold of SDRPlay binaries anyhow.
I will probably upload new installers tonight, since some hackrf users may appreciate working hackrf support. But I can always upload new installers as we fix and improve various support modules. So no rush.
This driver is a problem for MacPorts too. It would need to reference libs and include files outside of the MacPorts root which I don't believe is permitted. Also, even if this could be worked round it would need to auto download and install the driver before the install. This does't seem possible?
The best option would be for the driver to be added to the soapysdrplay repository as a binary when a release is made. That way, getting the soapysdrplay source would also get the dependant binary.
Let's hope mirics relaxes their distribution requirements as it greatly limits the ease of use of the sdrplay device in the open source community.
I'm happy to be responsible for pushing up the .so/.dll into the SoapySDRPlay repository when there are new releases. Does that satisfy the requirement? Maybe into /RPi, /Ubuntu/x86 /Windows etc.? I will check with the legal team if that is what is required? Not sure how that differs much though from running the .run installers from our website?
I'm only looking at the MacPorts option but it would allow a seamless install of sdrplay from MacPorts.
You would do
port install soapysdrplay
This would download and install dependency soapysdr and the soapysdrplay driver and binary and build in one hit, no user intervention required.
MacPorts would be happy to include this as they can test the build without having to manually install a vendor specific driver, which they don't support.
I'm hoping that once SoapySDR is in the MacPorts tree I can get the gr-osmosdr Port modified to include SoapySDR support as standard (I have the mods ready for that). This would then give seamless support to gnu-radio and gqrx.
Would require some changes the cmake file for soapysdrplay as it would not need to search for the header/lib files outside of the build tree.
Some clarification is needed here. My understanding is that you cannot test SoapySDRPlay without the hardware driver, which is closed source. This was a red line for MacPorts when I discussed with them about supporting gr-osmosdr in the same way as you are describing. So are you saying that the binary driver should NOT be part of the SoapySDRPlay repository? I just need some clarification on what SDRplay would need to do/provide for this to work. Thanks.
Was it the MacPorts team or the gr-osmosdr port maintainer? I was hoping the binary driver could be included with soapysdrplay.
The ffmeg MacPort has an option to include non free libraries and binaries which must not be redistributed further so I assumed we could follow the same pattern. I'll unpick the ffmpeg port file to see what they've done.
The MacPorts team. Let me know what you need me to do.
My mistake, having now unpicked the Ports which have a non free option they still build everything from source. It appeared as if some libs were coming down pre-built but they're not.