CubicSDR sluggish with SoapyRTLSDR v0.23 + async setting bug

[vsonnier]

@guruofquality @cjcliffe Good morning ! This is a bug entry for the latest SoapySDR v0.23 seen on CubicSDR both on latest Cubic v0.22 Win64 and the one provided in the PothosSDR-2017.05.02-vc14-x64.exe distribution. On both, CubicSDR OpenGL is sluggish as if "Limit CPU usage" option was ON constantly, while using a RTL-SDR. I tracked down the problem noticing that with SoapyRTLSDR module v0.22 CubicSDR was fast as hell as before.

Finally it goes down to 2 things:

• Changing in SoapyRTLSDR.hpp the constant #define DEFAULT_BUFFER_LENGTH back to 16384 restored the performance,
• I also noticed an affectation cut-n-paste bug in Streaming.cpp (261) where there is asyncBuffs = asyncBuffs instead of asyncBuffs = asyncBuffs_in, making the async buffer number setting inoperative.

I don't know if both changes are related, but recompiling SoapyRTLSDR v0.23 with the above changes restored the perfomance of the latest CubicSDR builds.

Seen on a Win7 x64 platform.

[guruofquality]

asyncBuffs = asyncBuffs_in

Opps fixed that

Changing in SoapyRTLSDR.hpp the constant #define DEFAULT_BUFFER_LENGTH back to 16384 restored the performance,

Just want to note that the change in buffer length was to address some sustained streaming rate that was working on another similar driver, and it turned out that this was the cause. Damned if you do, damned if you dont :-)

What do you mean by fast? Is it the switching time after setting frequency and we are seeing a lot of extra stuff in the buffer. We do clear the buffers after setting the frequency, but with the longer individual buffer chunks, it could be the sole reason.

[vsonnier]

@guruofquality Found the problem, see PR #29 :)