Alternate rtl-sdr package (rtl-dsr-x)



There is a fork of rtl-sdr that adds many bug-fixes and improvements to the original rtl-sdr code base. I have been asked to add it to our drivers repository and I think we could add it under a different name that provides the same library. I think users could then install it as an alternative to the existing rtl-sdr package.

We agreed to call it rtl-sdr-x, which will also be the name in pybombs.

I have never tried think but I think it is possible as I have seen something similar with other packages, e.g. libcurl.

Any thoughts?


@csete sounds good to me. Would you also like a repo for it under


It’s already on Github, I just forgot to add the link:


I was keeping an eye on this wondering what to do myself. It seems to be a drop-in replacement for the original librtlsdr.

  • Is there any downside to switching over to it entirely?
    • If this is better, why isnt it merged into the osmo git repository?
    • Did the two libraries diverge, and now each one has separate features or is one a subset of the other?
  • Is there an ABI difference? Additional C functions are fine, but changed function prototypes mean we cant switch between the two libraries because you would have to rebuild something like gr-osmosdr

…I can always diff the headers, but I genuinely don’t know about the other differences, politics, etc.

So long as they are ABI compatible, I like the idea of a swappable package, one named rtl-sdr-x. As soon has gr-osmosdr supports a new function in rtl-sdr-x with some ifdefs, then you cant really swap libraries and have both options. Theres other ways around that, like dynamic stuff dlopen and dlsym, or multiple source wrappers for rtl and rtl-x. I was thinking of a good way to handle something like this in SoapySDR (which would also help gr-osmosdr) would be to just build the SoapyRTLSDR package twice, against each library, and only change the name of the installed plugin for each build – so they could be packaged and installed side by side. If we get desperate :slight_smile:


Hi Josh,

No downside switching over. The patches we applied was on the osmo mailing list, and seens to be ignored since ever. That’s why we forked.

Our library has more features than the osmo one, like IR reader, RPC, Bias T, Input Bandwidth Filter Control and some fixes that improve the performance over the GHz band. We didn’t changed any of the function headers (the softwares that are on the market still work fine with this fork, including osmosdr). We just added some features and added some options that was on the mailing list and no one seens to care about.

The ABI is still the same but with some new functions that isn’t on osmo, but nothing that breaks compilation.

I can try again to ask them to merge our tested branch, but I’m not sure that they will merge (since there is like 40 patches on their “pipeline”).


Thanks @racerxdl I appreciate the info. I think that I will switch over my PothosSDR windows installer to this version of rtlsdr as well. Here’s some more patches for the pipeline :slight_smile:

@csete The fact that its basically additive means that compiling against librtl-sdr and installing rtl-sdr-x would probably work just fine. Of course we would figure out the provides/conflicts/replaces lines in the debian control and update the instructions with the new name.

But I also have half a mind to just say “lets do it” and give the existing librtl-sdr a bumped version number and just switch to the new codebase.


Hi guys,

I’m fine with replacing the existing librtlsdr with the new one, in particular if there is little chance that the old one will get a new release.

Unfortunately, I don’t have time during the coming weeks (all my stuff is packed down) so feel free to package it if you want. Otherwise I will do it when I get the time.


@racerxdl I taken to a habit of checking in the debian/* control files along with the source code for many of my projects. I then use git buildpackage to build source packages to upload. What do you think about doing the same with librtl? There might not be a ton of value now, but supposing that there are modifications to the debian files for new manpages, binaries, or other that were not in the original library; it would be nice to version it along with the source.


Sure @joshblum, that looks a good idea. I never used git buildpackage, I will read about and change the repository to be able to generate debian packages like that.