conflict with SoapySDRplay2 library

[ra1nb0w]

SoapySDRPlay3/CMakeLists.txt

Line 49 in e315129

TARGET sdrPlaySupport

should be sdrPlay3Support to avoid file conflict with sdrPlaySupport from SoapySDRplay2?
Generally I need both Soapy API version because gr-osmosdr supports only the second version.

[fventuri]

Good catch @ra1nb0w - I just created a new branch called 'change_library_name_to_sdrPlay3Support' (https://github.com/pothosware/SoapySDRPlay3/tree/change_library_name_to_sdrPlay3Support), that will generate a SoapySDR module library called libsdrPlay3Support.so to avoid conflicts with version SoapySDRPlay2

Also if you are using gr-osmosdr to run gqrx, please be aware that I and a few other people were able to run gqrx with the new version of the SoapySDR driver (SoapySDRPlay3) - see for instance this discussion thread: #21

Franco

[jketterl]

Just a word of caution: I'm not sure how SoapySDR will handle this, but this may cause problems since both libraries will export the same "sdrplay" factory / driver name. As far as I'm aware, this is how SoapySDR chooses the underlying library, so in the best case, this will make for some pretty random choices of underlying driver.

Changing the driver / factory name however could result in compatibility issues.

I think the best solution would be to update gr-osmosdr to support driver version 3, it's the current version and I'd expect version 2 to be dropped at some point in the future.

[guruofquality]

@jketterl thats correct. SoapySDRPlay3 was supposed to be a replacement, so just renaming the library to coexist with the old wont be enough without also changing the driver keyword thats associated. otherwise you will see the duplicate entry error print at initialization. Probably would be random as to which module gets loaded first :-)

[SDRplay]

SoapySDRPlay3 should remain as sdrplay so as to make things as smooth as possible - SoapySDRPlay2 can be renamed to something else as API 2 is now just to support legacy installs.

Everyone ok with that?

[fventuri]

@jketterl - Jakob, you may want to check out this fork of gr-osmosdr https://github.com/fventuri/gr-osmosdr , since it should support SDRplay API version 3.X ( @nmaster2042 reported success using it).

On the other hand, if the main reason to use the gr-osmosdr module is to run the SDR application gqrx, I know of a few of us (me included) who were able to run gqrx with the SoapySDRPlay3 driver (and SDRplay API version 3.X).

Franco

[jketterl]

I'm not the OP, I think that should probably go to @ra1nb0w ;)

[SDRplay]

To be clear, I'm not bothered about the name of the .so, but I am concerned about the "driver=" name - this needs to be as seamless for people as possible going from SDRplay\SoapySDRPlay to pothosware\SoapySDRPlay

[ra1nb0w]

@SDRplay In my opinion remaining the past is not a good idea because create confusion and generally break many already working software. Obviously, the file name is only an issue and other things should be aligned.

[ra1nb0w]

@jketterl - Jakob, you may want to check out this fork of gr-osmosdr https://github.com/fventuri/gr-osmosdr , since it should support SDRplay API version 3.X ( @nmaster2042 reported success using it).

Why you don't try to send it to upstream? they re-started to accept contributions. Until that end, I cannot use it on macports.

[fventuri]

@ra1nb0w - Thanks for the useful suggestion.
I am not sure if anyone with a Mac has ever tested the fork of gr-osmosdr, so I think it would be prudent to have at least one Mac user give it a try before pushing it upstream.

Also I am not really sure what is the right upstream for gr-osmosdr; here: https://github.com/osmocom/gr-osmosdr ? or here: https://git.osmocom.org/gr-osmosdr/ ?
As far as I can tell neither repository has a place for users like you to report the issues that they find; I probably missed something while looking around.

Franco

[ra1nb0w]

@ra1nb0w - Thanks for the useful suggestion.
I am not sure if anyone with a Mac has ever tested the fork of gr-osmosdr, so I think it would be prudent to have at least one Mac user give it a try before pushing it upstream.

It works, at least on my macOS 10.14.

Also I am not really sure what is the right upstream for gr-osmosdr; here: https://github.com/osmocom/gr-osmosdr ? or here: https://git.osmocom.org/gr-osmosdr/ ?

In the past you had to use osmocom (redmine and git) maybe nowadays it is changed (github is only a mirror).
Try to contact argilo (https://github.com/argilo). He is very kind and should help you (since he is mentoring other patches for gr-osmosdr).

[nmaster2042]

@fventuri the official upstream for gr-osmosdr is https://osmocom.org/projects/gr-osmosdr
The github repo is mirrored, read only if I have understant it correctly.

It seems there is some activity in 2020 contrary to what happened in the past years.
See here: https://osmocom.org/projects/gr-osmosdr/activity
So maybe a hope to PR a good sdrplay devices in the official gr-osmosdr.

[fventuri]

Thanks for the useful info @ra1nb0w and @nmaster2042
Once the work on the changes to the driver SoapySDRPlay3 for issue #23 is completed, my next task will be getting the code in the gr-osmosdr fork ready for upstream (I need to look into the issue with the demodulation described by @nmaster2042 here fventuri/gr-osmosdr#1 first).

Happy New Year!
Franco

[ra1nb0w]

thank you @fventuri for all your effort and work!