I tried the “Alternative Debian Package Installation Method” instructions for a V4L on a Raspberry Pi. It generated a bunch of errors and warnings about obsolete sources then failed at git clone https://github.com/osmocom/rtl-sdr
Can you post the exact commands, and error messages that you got?
THIS actually is where the errors happened ... I guess I needed more coffee ... kd4e-trrs@raspberrypi:~ $ cd rtl-sdr
kd4e-trrs@raspberrypi:~/rtl-sdr $ sudo dpkg-buildpackage -b --no-sign
dpkg-buildpackage: info: source package rtl-sdr
dpkg-buildpackage: info: source version 2.0.3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Steve Markgraf <steve@steve-m.de>
dpkg-buildpackage: info: host architecture arm64
dpkg-source --before-build .
debian/rules clean
dh clean --buildsystem=cmake
dh_auto_clean -O--buildsystem=cmake
dh_autoreconf_clean -O--buildsystem=cmake
dh_clean -O--buildsystem=cmake
debian/rules binary
dh binary --buildsystem=cmake
dh_update_autotools_config -O--buildsystem=cmake
dh_autoreconf -O--buildsystem=cmake
libtoolize: putting auxiliary files in '..'.
libtoolize: copying file '../ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:16: warning: The macro 'AC_PROG_LIBTOOL' is obsolete.
configure.ac:16: You should run autoupdate.
m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
configure.ac:16: the top level
configure.ac:28: warning: The macro 'AC_HEADER_STDC' is obsolete.
configure.ac:28: You should run autoupdate.
./lib/autoconf/headers.m4:663: AC_HEADER_STDC is expanded from...
configure.ac:28: the top level
configure.ac:93: warning: The macro 'AC_TRY_COMPILE' is obsolete.
configure.ac:93: You should run autoupdate.
./lib/autoconf/general.m4:2845: AC_TRY_COMPILE is expanded from...
configure.ac:93: the top level
configure.ac:111: warning: The macro 'AC_CONFIG_HEADER' is obsolete.
configure.ac:111: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:111: the top level
configure.ac:113: warning: AC_OUTPUT should be used without arguments.
configure.ac:113: You should run autoupdate.
configure.ac:12: installing './compile'
configure.ac:15: installing './config.guess'
configure.ac:15: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:15: error: required file './ltmain.sh' not found
configure.ac:5: installing './missing'
Makefile.am:4: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '_CPPFLAGS')
src/Makefile.am:6: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '_CPPFLAGS')
src/Makefile.am: installing './depcomp'
autoreconf: error: automake failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:6: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
kd4e-trrs@raspberrypi:~/rtl-sdr $
The exact commands are at RTL-SDR Blog V4L (Lite) Users Guide Alternative Debian Package Installation Method
If you have a system reliant on the Debian packages (eg. FlightRadar24, FlightAware, ADSBExchange, OpenWebRX+ images) you can update them directly using this method:
sudo apt update
sudo apt install libusb-1.0-0-dev git cmake build-essential pkg-config build-essential
sudo apt install debhelper
git clone https://github.com/osmocom/rtl-sdr
cd rtl-sdr
sudo dpkg-buildpackage -b --no-sign
cd ..
sudo dpkg -i librtlsdr0_*.deb
sudo dpkg -i librtlsdr-dev_*.deb
sudo dpkg -i rtl-sdr_*.deb
kd4e-trrs@raspberrypi:~/rtl-sdr $ sudo dpkg-buildpackage -b --no-sign 2>&1 | tee build.log
grep -n -B5 -A10 -E 'error:|automake failed|autoreconf' build.log
dpkg-buildpackage: info: source package rtl-sdr
dpkg-buildpackage: info: source version 2.0.3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Steve Markgraf <steve@steve-m.de>
dpkg-source --before-build .
dpkg-buildpackage: info: host architecture arm64
debian/rules clean
dh clean --buildsystem=cmake
dh_auto_clean -O--buildsystem=cmake
dh_autoreconf_clean -O--buildsystem=cmake
dh_clean -O--buildsystem=cmake
debian/rules binary
dh binary --buildsystem=cmake
dh_update_autotools_config -O--buildsystem=cmake
dh_autoreconf -O--buildsystem=cmake
libtoolize: putting auxiliary files in '..'.
libtoolize: copying file '../ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:16: warning: The macro 'AC_PROG_LIBTOOL' is obsolete.
configure.ac:16: You should run autoupdate.
m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
configure.ac:16: the top level
configure.ac:28: warning: The macro 'AC_HEADER_STDC' is obsolete.
configure.ac:28: You should run autoupdate.
./lib/autoconf/headers.m4:663: AC_HEADER_STDC is expanded from...
configure.ac:28: the top level
configure.ac:93: warning: The macro 'AC_TRY_COMPILE' is obsolete.
configure.ac:93: You should run autoupdate.
./lib/autoconf/general.m4:2845: AC_TRY_COMPILE is expanded from...
configure.ac:93: the top level
configure.ac:111: warning: The macro 'AC_CONFIG_HEADER' is obsolete.
configure.ac:111: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:111: the top level
configure.ac:113: warning: AC_OUTPUT should be used without arguments.
configure.ac:113: You should run autoupdate.
configure.ac:12: installing './compile'
configure.ac:15: installing './config.guess'
configure.ac:15: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:15: error: required file './ltmain.sh' not found
configure.ac:5: installing './missing'
Makefile.am:4: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '_CPPFLAGS')
src/Makefile.am:6: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '_CPPFLAGS')
src/Makefile.am: installing './depcomp'
autoreconf: error: automake failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:6: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
grep: build.log: No such file or directory
This is precisely why I built the driver directly into VibeSDR. I am aiming for VibeSDR and its ecosystem to be as simple as possible whilst still being powerful enough to be a good SDR app.
I have built in drivers for RTL-SDR including the V4L (I am running one on my server right now you can connect to) HackRF, AirSpy HF+, the only one you need to install drivers for is SDRPlay because of the licensing and if you dont have an SDRPlay then don’t install them they arent a dependency needed for the app to function.
I looked at that and it seemed to be way more than I needed. (How much overhead does the VibeSDR add, please? This is on a RaspberryPi 4B 8g that’s already a little slow.) I just need to get things to play nicely with the V4L. NOTE: I’m using trunk-recorder and radio-scout (an alternative to the rdio-scanner and ThinLine Radio front ends). Thanks!
I run 4 Radios at a time on a Pi5 and it uses around 25% running a DAB decode
If you want to take a look
That is with 2 users connected and the RSP1B running a full 8MHz spectrum 24/7
So your Pi4 will be more than enough, my eventual goal if they ever get back in stock is to have VibeServer running on Raspberry Pi Zero 2 W so that you could 3D Print or cable tie an RTL-SDR to it, connect it to a battery and antenna, and then lob the thing up a tree whilst you sit and connect to it on your phone to listen in. To that end I made sure EVERYTHING was as optimised as can be using full SIMD/NEON instructions to get the most out of the processor, porting DAB to NEON resulted in a 16-20x speedup on something that was already fast enough.
The only thing that you will need to do for now is to connect to your other apps via the audio route as there is no RAW IQ out and unfortunately I don’t support the digital voice modes as they all require licensing and patents to keep everything above board. DAB I can get away with because MP2 is so old I can include a decoder for that and AAC gets decoded by the servers own OS level AAC decoder before being sent out so no codecs needed in the app itself.
There is an option for uncompressed audio output so if you are feeding audio into other apps it will be nice and clean and free from compression artefacts.
So seeing your use case with trunk radio recording I have decided to add a RAW IQ out mode to VibeServer so that you can funnel the IQ via RTL-TCP protocol into your apps. If doing it on the local network it will all be self contained and you simply point your app to the IP address of the server, if sending it via the tunnel publicly Cloudflare tunnels don’t have ports so I will be building a little VibeIQ app to connect to the IQ stream and convert it to RTL-TCP for you.
In theory is enough servers enable IQ out you’ll be able to use your apps on other peoples radios. 250K IQ out on local network and 48K over the tunnel.
You’re talking a wee bit ‘fast’ for me to keep up. 
Seriously, my application is for local scanner use. Stationary or mobile/portable (the radio-scout front end doesn’t feed scanner streaming services). I need to decode P25 Phase 2 and am unaware of any licensing problem on the receive-only side.
It is the audio codec used to decode the digital voice modes. It is patented Digital Voice Systems inc and I cannot legally include it. Other apps get around this by not being in the app stores etc. However your decoder apps should have the option for RTL-TCP input, if they do what I am building now will help you. It means you can use the RTL-SDR V4L as a plug and play device with no driver issues as I include the driver built into the app itself its all self contained, but you can then send the RAW IQ data directly to your decoders.
It means you get a general purpose SDR that you can access anywhere in the world over the internet, but you can use your digital voice apps when you are at home.
RTL-TCP output is now working on local networks. If you do use VibeServer go into the audio button in the web client and enable IQ out, this will give you the address and port, enter that into your P25 app if it supports RTL-TCP and it should work for you.
VibeServer also has a custom RF Auto Gain that I designed for RTL-SDR’s as the inbuilt one doesnt work well, so if you have that enabled you get the auto gain benefit too so your signals wont overload.
In the screenshot that is VibeServer’s Web Client sending its RAW IQ out and then SDR++ receiving it, substitute SDR++ for your P25 app and you should be good to go.
I am working on the public tunnel side of this now, so that shouldnt take too long I hope.
I need to block diagram this … [VibeServer] captures the digital audio using the V4L, but doesn’t process it → [Trunk-Recorder] decodes the captured P25 audio → [Radio-Scout] manages the decoded audio. Is that correct?
For P25 yes, for any other analogue mode VibeServer can do it itself.
Including NXDN and DMR Tier III? (A friend needs NXDN for their local public service system.) Ooops, you said “analog modes”.
If they have the apps for them then yes, the RAW IQ acts as if a real RTL-SDR has been plugged into the receiving app, that app doesnt know that the IQ data is coming from another app. It just needs to know it can send tuning commands and then has IQ data to work with.
In RTL-TCP mode VibeServer basically acts like a virtual RTL-SDR, just limited in bandwidth.
I’ve asked about VibeServer “a little VibeIQ app to connect to the IQ stream and convert it to RTL-TCP” and Trunk-Recorder playing nicely together on the Trunk-Recorder Discord.
This is all the bandwidth that’s needed for our local system: “center”:856537500,
“control_channels”:[
856937500,
856812500,
856737500,
856487500,
856362500,
856137500