Fix uninitialized tunerGain in SoapyRTLSDR constructor

[cozycactus]

This pull request addresses an issue within Gqrx where the tunerGain variable in the SoapyRTLSDR constructor remains uninitialized. As a result, when switching between different SoapySDR drivers, the tunerGain can assume abnormally large values, causing the Gqrx interface to become excessively wide and disrupting the user experience.

[zuckschwerdt]

Good find, thanks. Though most of these, e.g. sampleRate, centerFrequency, will be wrong until the first set*() call. We'll need to test if librtlsdr produces sensible values on startup and read those, perhaps in the constructor or perhaps on first call (using an out of bounds dummy value). Are you interested to test that, are read values on cold or warm start of an rtlsdr sensible?

[cozycactus]

i suppose values you mentioned have to be in proper range too..

how do you want me to test it? i'm interested

[zuckschwerdt]

Currently the constructor sets some default values (like your 0.0 for gain), and the get-calls return that bogus value. It would be interesting what the rtlsdr_-calls (like tunerGain = rtlsdr_get_tuner_gain(dev) / 10.0 return on first call, maybe in the constructor. Are there sensible values before any first set-call? Are the values from a warm start (previously accessed rtlsdr) still there? If that all works out we'd need to decide wether to put a number of rtlsdrget-calls in the constructor or put them as if (value invalid) { value=rtlsdr_get_ } in the get-calls (with an init to invalid too).

[zuckschwerdt]

Oh, sorry, I just remembered that rtlsdr does not issue any (i2c) read calls but always returns the cached value from the last write. Scrub the idea, get-calls will always be bogus until the first set-call.