Make stream deactivated before a sample-rate change and reactivated afterwards

[vsonnier]

Origin : #716 where LimeSDR do not like setSampleRate while streaming. This PR changes CubicSDR behaviour to shut-up stream with deactivateStream before doing the sample rate change, then only activateStream again at the end.

I've tested this on RTL-SDR, SDRPlay RSP2, Adalm-PlutoSDR on Windows10 1809 x64. With these, changing sample rates works neither better nor worse that before.

I've also tried these devices through a (localhost) SoapyRemote connection, everything is fine.

For these devices at least, the change if not visibly longer on CubicSDR.

[vsonnier]

@Dantali0n @juribeparada @guruofquality you can now give it a try with LimeSDR.

[Dantali0n]

Works great on LimeSDR-USB, time taken between deactivate / activate is significantly decreased as well. Audio & waterfall stutters persist at 65Mhz sampling but that is just a limitation of my computer. MTU seems now to be consistently set to 4080 haven't seen other values.

[juribeparada]

I can confirm that LimeSDR-USB works great (I also see a significant decrease of deactivate/activate time), but unfortunately this PR breaks LimeSDR-Mini when I try to change the sample rate. It looks like LimeSDR-Mini works OK only when changing sample rate while streaming(!), totally the opposite of LimeSDR-USB. The commit
ed59937 works OK for LimeSDR-Mini because it was specific for LimeSDR-USB. For example, if I change:
device->getHardwareKey() == "LimeSDR-Mini"
it also breaks LimeSDR-Mini support, the same behavior of this PR. Be aware I only tested on macOS Mojave.

[juribeparada]

OK, now I tested this PR on Ubuntu 18 (run native in other PC), and it works great for LimeSDR-USB and LimeSDR-Mini, even solves the "limitation" of sample rate < 5 MSPS in LimeSDR-Mini.
It seems to me my problem in macOS is related to a known bug with LimeSDR-Mini: when the stream is closed properly, then LimeSDR-Mini will not work for a next re-opened stream, you need to unplug and plug the device. A very ugly bug that only affects macOS and LimeSDR-Mini, not sure if that bug has a solution currently. Also I tried an Ubuntu 18 VM in my Mac, and the problem persists, then seems a hardware related issue (LimeSDR-Mini uses FT601 USB interface, but LimeSDR-USB uses FX3 device).

[vsonnier]

MTU seems now to be consistently set to 4080 haven't seen other values.

also...

It looks like LimeSDR-Mini works OK only when changing sample rate while streaming(!), totally the opposite of LimeSDR-USB.

Well looks like both devices have serious problems of changing samplerates, that somewhat got fixed by accident and broken the other way.
Funny thing, both statements above suggests some things are actually up to date (MTU) only once the streaming has actually started.
Ok let's try this then, which is actually closer to Cubic master:

1. SoapySDR::Device::deactivateStream : be safe, make the device quiet before changes
2. SoapySDR::Device::setSampleRate : User command, changing sample rate
3. SoapySDR::Device::activateStream : back to business.
4. Re-read SoapySDR::Device::getSampleRate and SoapySDR::Device::getStreamMTU : Re-do buffer setup on Cubic side.

[juribeparada]

Now tested 3355111 on macOS and Linux, and I get the same results as before, all work great with high/low sample rates, except LimeSDR-Mini on macOS, due to the specific issue commented before (see https://discourse.myriadrf.org/t/limesdr-mini-macbook-pro-a1398-high-sierra-10-13-6-usb-hub-success/3326). I will try to find more information about the LimeSDR-Mini / macOS problem.

[Dantali0n]

This works as well.

[juribeparada]

Please look at myriadrf/LimeSuite#254
With a small modification in libusb, LimeSDR-Mini on macOS works great with this PR.

[vsonnier]

Thanks @juribeparada for all your investigation on this problem !
I could commit this PR this master as it is, but I would like to have people try with other supported devices like Airspy, HackRF... to cover the most popular to see if the sample rate sequence change have not broken those devices.

@guruofquality, Charles ( @cjcliffe ) could you give it a try and report if you have such devices ? Thank you.

[cjcliffe]

@vsonnier code changes look solid; going to give it a go with AirSpy and HackRF here.

[cjcliffe]

@vsonnier all looks good here with SDRPlay RSP1A & RSP2, Airspy Mini and HackRF on Ubuntu 18.

[vsonnier]

Thanks @cjcliffe and all for your feedback, I think we cover the most used devices now. Time to make these changes live !

[digitalresistor]

Sorry to ask a question on a closed PR, but when can we expect a new release with this change (preferably with a new build for macOS)?

[cjcliffe]

@bertjwregeer hoping to wrap up some more bugs and get an 0.2.6 build out in early June