Due to the recent UHD PPA updates I went on and built the relevant packages (gnuradio and up) for Ubuntu 16.10. Unfortunately, the known crash issue has not been resolved in the latest UHD so the packages are pretty much useless for anything that has a runtime link to UHD.
Therefore, I have rebuilt gr-osmosdr with UHD support disabled and things are now working fine – well at least gqrx.
I hope it’s OK that I did this without asking first. I really see no choice since programs like gqrx crash without any possibility to work around it, except disabling UHD support in gr-osmosdr.
That sucks, but I understand. I should also have to rebuild SoapyUHD and gnuradio (gr-uhd), as technically the ABI changed. I guess it would still crash due to the boost issue. If I get a moment. I will see what my yakkety VM does.
I just copy & pasted from an old email from when I tested using 16.10 packages. The latest binaries from PPA also point to boost::asio::detail::task_io_service::shutdown_service()
Just for a data point - I ran uhd_usrp_probe and uhd_find_devices on a yakkety VM for both packages (ubuntu and from ppa) and neither command crashes. I will have to see what the osmosdr blocks do. I wonder if there is a synergy between one of the osmo devices using boost asio and uhd.
I will be looking into adding gr-iio support to gr-osmosdr in the coming weeks and will try to see if I can spot anything in the UHD code. I know the RFSpace backend has the option of using boost asio, so what you say sounds plausible.
I will also have to tell Dimitri about my patches that we have in the PPA. I’ve got good feedback from field testing so they work well.
Does it mean that soapy devices will be included in the gr-osmosdr device list? That would be nice
On a different note, I am wondering if you are aware of any discussions regarding the future of gr-osmosdr? It seems to me that soapysdr with a gr-soapy block would be more feasible way forward. I am yet to use it in a real project, but I think the plugin architecture and the fact that it is available outside GNU Radio makes it more fit for the purpose.
Does it mean that soapy devices will be included in the gr-osmosdr device list? That would be nice
Yes. I was wondering why they were missing. Turns out that I forgot to put my ifdefs in the devices code.
On a different note, I am wondering if you are aware of any discussions regarding the future of gr-osmosdr? It seems to me that soapysdr with a gr-soapy block would be more feasible way forward. I am yet to use it in a real project, but I think the plugin architecture and the fact that it is available outside GNU Radio makes it more fit for the purpose.
I’m not aware of any discussion. I was sticking with gr-osmosdr because its a well known API that many people use and build. And with the soapy support, it is effectively modular. You could configure gr-osmosdr for only soapy support and you would still be able to support most of the devices out there.
I think that a gr-soapy source/sink in mainline gnuradio would be tremendously helpful in terms of developer burden and supporting hardware. But its just a question of what the community is willing to use. But if there was interest, I would be supportive.