Splitting up device args - tune and stream args

[guruofquality]

We have some device arguments which I think are more or less inherited from the Osmo code, but there may be more fitting ways to deal with them in the API.

Stream args

These are device args that could be passed to setupStream()

• "buflen" and "buffers" are stream args and affect the stream buffer allocations
• "iq_swap" sounds to me like is also a stream modifier
• "direct_samp" also a stream modifier?

  Tune args

These are device args that could be passed to setFrequency()

• "offset_tune" could be used to modify rtlsdr_set_offset_tuning only when specified in the tune arguments for setFrequency()
• "corr" - it looks like this device arg was intended to be redundant with the "CORR" frequency component which calls rtlsdr_set_freq_correction

  Possible bugs?

• current the device arg "corr" and "direct_samp" look like they are parsed, but not actually used

  Pros/cons/thoughts...

• Putting things into the device args is a convenient way to specify extra settings via many of the command line applications because nothing has to be changed about the code. So quite a lot has been crammed into args.
• Second, RTL is a single channel device, so device-wide args work in this situation -- so long as we dont have multiple channels with heterogeneous settings.
• We could continue to use device args as the defaults to the tuner or stream args when they are not specified by the user on a per-channel basis, this would keep the old "API" in-tact.

[cjcliffe]

The device args were mostly there as I hadn't really thought about their usage and was getting familiar with the order-of-operations -- I've moved the relevant ones over to stream args now and offset_tune to the setFrequency() which makes sense.

I've removed corr from device/stream init since it doesn't make sense to have in two places. I was considering this as an alternate at first since the BladeRF driver throws an invalid name error when corr is specified: if (name != "RF") throw std::runtime_error("setFrequency("+name+") unknown name"); -- so I assumed this is default behaviour.. For now I've just filtered it's availability by driver name.

[guruofquality]

Just in case this was missed, sid you see the call std::vector<std::string> listFrequencies(const int direction, const size_t channel) const (awkwardish name). But it should be a list of all available tunable components. Blade RF would only have "RF". Many devices with CORDICs in the digital baseband have "RF" and "BB".

[cjcliffe]

Thanks, I missed that one -- I think I expected a "getFrequencyNames" or something like that -- will implement that instead of my module name checking.

[guruofquality]

FWIW, I like that name better. I churned these functions out really quickly, and going back the naming is clearly a little awkward. Everything that returns a string vector should probably be getSomethingNames(). It might be good to rename them for the next round of changes -- just in a way that keeps prior client code and modules operating.