Make the streaming implementation more robust

[fmoessbauer]

This PR mainly addresses the following issues:

• no exceptions in streaming API (use return codes instead)
• no logs on certain (common) events (this otherwise breaks the stream indicators when using SoapySDRUtil rate testing
• Fulfill soapy's client behavior expectations
• Bump minimal CXX version to 11 (this is necessary for SoapySDR anyways)

[fmoessbauer]

Note: a good testing tool is the SoapySDRServer application, together with SoapySDRUtil --args="driver=remote" --rate=1e6 --direction=RX. This enforces lots of corner-case scenarios, like broken streams, overflow / underflow, etc.

[fventuri]

Thanks Felix for your changes.

One thing that I am still grappling with is the best way to handle streaming failures with CubicSDR (which is what many users would probably use this module for); by throwing an exception I was forcing the application to somehow deal with it (in my case CubicSDR was throwing a core dump), while returning an error code (which is what the specs for SoapySDR drivers say you should do) causes CubicSDR to just freeze; I was able to make this happen in at least a couple of ways (switching the RSPduo mode from single tuner to master while streaming, or just stopping the sdrplay_api service while streaming and then trying to change the device in CubicSDR).

Again this is probably something that the SoapySDRPlay driver shouldn't have to worry about, but in my case having a core dump made my life easier while troubleshooting what went wrong.

Franco

[fmoessbauer]

Hi @fventuri ,

the streaming failures are indeed not properly handled in CubicSDR. However this should be fixed in Cubic. Soapy provides all the necessary information, so this should not be a "conceptual" problem. In the meantime, we could also add a CMake option (together with a define), to throw on streaming errors.

Another open question is still if the current implementation of the streaming API is actually race-free. There are some indications that it might be not: pothosware/SoapySDRPlay3#59

In my use-case I have a remote SDR station and there I got the problem, that something crashes after a few hours to days. However, this could also be related to a crash of the SDRPlay service. I hope, I will find the time to investigate this more closely.

[fventuri]

Felix,
last night a wrote a simple C program (attached) based on the 'sdrplay_api_sample_app.c' example in chapter 4 of the API Specification v3.06 manual (https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.06.pdf).
This program just streams off the RSP, and every so often (5 minutes in the code attached) prints out a line with the number of samples received since the previous output, the average sample rate in the interval, and the total number of samples received since the beginning.
I let it run for about 22 hours on my PC, and the output didn't show any error or 'skipped' samples, so for what I can tell the sdrplay_api_service seems to be able to handle streaming for about a day without interruption.
Since you say that the time it takes to crash can vary significantly, I just started another run for another 24 hours or so, and I'll let you know how it goes.

Franco

sdrplay_api_long_test.tar.gz

[fventuri]

Felix,
I let the streaming program in C run for another 2 and a half days, and I didn't see any crashes or other problems here.

Franco

[fmoessbauer]

Hi Franco,
Thanks for this effort. I did also run some tests with this soapy implementation and it did not crash either. Probably it happened during config changes while streaming. I plan to investigate this further and report back again.

Felix