Re-purpose remote-enabled EEPROM flag to determine if direct sampling mode should be forced ON. Useful for apps that don't have any direct sampling mode settings in their GUI.
Re-purpose remote-enabled EEPROM flag to determine if direct sampling mode should be forced ON. Useful for apps that don't have any direct sampling mode settings in their GUI.
Use the offset tuning button to enable the bias tee on the V3. Offset tuning is not used for the R820T so this is okay and allows us to toggle the bias tee on software that hasn't implemented specific bias tee controls.
Although we added a detection mechanism for the presence of the Kernel
bug earlier, reading from the incorrectly mapped memory might cause a
bus error on some ARM systems.
With the overall performance benefit being rather minimal for the
data rates of rtl-sdr, disable zero-copy by default.
Removed the linked list structure, locking, and malloc/free on each USB callback.
Replaced it with a non blocking ring buffer for performance. This resulted
in a large performance improvement when using an Raspberry Pi or Raspberry Pi Zero W
as a rtl_tcp server. The sample rate could be doubled and instead of wired ethernet
wifi could be used. Frequnecy change lag was reduced greatly also.
Signed-off-by: Stephen Blinick <stephen@stesoft.com>
The Linux Kernel has a bug on ARM/ARM64 systems where the USB CMA
memory is incorrectly mapped to userspace, breaking zerocopy.
When the Kernel allocates the memory, it clears it with memset().
If the mapping worked correctly, we should have zeroed out buffers,
if it doesn't, we get random Kernel memory. We now check for this,
and fall back to buffers in userspace if that's the case.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
With just 'inline', if the compiler decides not to inline them, it isn't
required to emit them at all. For some targets with -Os that is causing
build failures, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360.
Perhaps we might consider using '__attribute__((always_inline))' for
GCC builds, but 'static inline' is a good start.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
During "make uninstall", the documentatin was not deleted properly,
if DESTDIR was used. The existing commands expanded to:
make[3]: Entering directory '/home/osmocom-build/jenkins/workspace/master-rtl-sdr/a1/default/a2/default/a3/default/label/osmocom-master-debian9/librtlsdr-0.5.4.5-5c30/_build/sub'
cd /tmp/am-dc-24621/ && rm -rf /home/osmocom-build/jenkins/workspace/master-rtl-sdr/a1/default/a2/default/a3/default/label/osmocom-master-debian9/librtlsdr-0.5.4.5-5c30/_inst/share/doc/librtlsdr/librtlsdr-0.5.4.5-5c30/html
This fixes the "make distcheck" step of rtl-sdr, and hence should also
fix the long-standing jenkins build verification for rtl-sdr
at https://jenkins.osmocom.org/jenkins/job/master-rtl-sdr/
Signed-off-by: Harald Welte <laforge@gnumonks.org>
As pointed out by Carl Laufer on the mailing list,
turning the loop-through output off reduces the
current consumption by 10-20mA which in turn reduces
the heat a bit. So far there seem to be no devices
that have anything connected to the loop-through output.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
This code stayed unchanged for many years, but for some reason
rtl_adsb started hanging upon exit:
*b66116a5164b69281eacc42ae950;
^CSignal caught, exiting!
<------ hangs here forever
Examining it with gdb reveals that the demod thread waits
peacefully on the condition variable, which we're trying to
destroy. Either the signals killed all threads before, or
condition variables were possible to destroy while other
threads still waited on them.
The easiest fix appears to be just cancel the demod thread
and wait for it to exit before proceeding for the door.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Decreases CPU load especially for embedded machines.
Requires Linux >= 4.6 and libusb >= 1.0.21. If this
is not the case or the allocation fails, we will
fall back to buffers allocated in userspace.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
