If the tuner doesn't support setting the bandwidth, wouldn't returning -ENOTSUP be more appropriate ? Or some other error code telling the calling application that the operation isn't supported ?

Similar functionality was developed by Leif Asbrink for Linrad. See http://lists.osmocom.org/pipermail/osmocom-sdr/2015-February/000019.html I have them in my fork (https://github.com/dl8aau/librtlsdr/commit/1bbe76a166b313f800747d10d91c9f97… and https://github.com/dl8aau/librtlsdr/commit/2332d3a43bc1a66c30a66f77b7ce6b9a…). Please have a look. Regards, Alexander

Hi Jiří, On 04/14/2015 05:17 PM, Jiří Pinkava wrote: As long as you did not change the functionality... Leif did extensive testing on the performance improvement on R820T. I don't think he is keen on repeating all that. At first sight it looks similar, but need to check more thoroughly. I already discussed with Leif internally before. There are good arguments for both versions. One being the fact that the gain is exported more or less same way (rtlsdr_get_tuner_gains) and another that the calling software should not need to know the tuner internals if possible. But I do not have a strong opinion there. The API is not really consistent. There are set and get functions that try to set a given parameter and return the setting actually in use. Then there is rtlsdr_get_tuner_gains() that returns a list of supported values. And exotic functions like rtlsdr_set_tuner_if_gain() that only make sense for E4000 knowing the internals. Just by looking at the distribution, I think the first kind is the most common - so maybe a rtlsdr_set_tuner_bandwidth() / rtlsdr_get_tuner_bandwidth() [returning the bandwidth in use]? But again: personally I do not mind (much). Regards, Alexander