pothosware / SoapySDRPlay2

Soapy SDR plugin for SDRPlay
MIT License
51 stars 11 forks source link

packaging? and dealing with SDRPlay drivers #3

Closed guruofquality closed 4 years ago

guruofquality commented 8 years ago

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

cjcliffe commented 8 years ago

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.

SDRplay commented 8 years ago

@cjcliffe We can certainly host binary packages of SoapySDRplay if that is ok with you. I'll email you directly to discuss.

cjcliffe commented 8 years ago

@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 :)

guruofquality commented 8 years ago

@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

cjcliffe commented 8 years ago

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.

cjcliffe commented 8 years ago

SDRPlay test unit arrived today; should now be able to get any remaining issues cleaned up and optimized :+1:

cjcliffe commented 8 years ago

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.

guruofquality commented 8 years ago

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.

gedger commented 8 years ago

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.

SDRplay commented 8 years ago

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?

gedger commented 8 years ago

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.

SDRplay commented 8 years ago

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.

gedger commented 8 years ago

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.

SDRplay commented 8 years ago

The MacPorts team. Let me know what you need me to do.

gedger commented 8 years ago

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.