* Clean up the CMake build system and improve the FindFFTW3 module.
* Fixes for Linux build
* Include winsock.h to get struct timeval
* Couple more fixes for MSVC, also add new FindMath module
* Update host build README for new CMake changes (esp. Windows)
* Try to fix Travis OS X build error
* Add docs about pthread-win32
* Whoops, AppVeyor caught a bug in FindFFTW where the includes not being found weren't generating a fatal error.
* Travis rebuild bump
* One more fix: replace hardcoded include paths with a PATH_SUFFIX to standard include paths
* Invert Windows preprocessor flag so it's only needed when using a static build. This preserves compatibility with the previous system.
* Fix copy-paste error
* Update cmake modules from amber-cmake upstream, incorporate TryLinkLibrary into FindUSB1
* Fix missing include
My previous commits didn't handle the specific case of hackrf_close()
being called without the transfers being active.
In this instance the transfers haven't been setup, so calling
cancel_transfers() returned an error.
Instead:
* refactor out the tx/rx stop command from canceling transfers
* send the tx/rx stop command without canceling transfers, since ..
* ... we can then destroy the transfer thread.
I may also need to put an explicit cancel_transfers() before the
call to send the tx/rx stop commands; I'll look at doing that
in a subsequent commit.
This seems to stop consumers that are doing quick back to back stop/start
(eg gqrx changing decode mode / filter bandwidth) from hanging the
device.
I now don't have any weird hangs on hackrf with gqrx/freebsd/libusb!
When things hang it isn't erroring out in any way; it just doesn't
start receive. It doesn't look like a libusb issue; I'd have to get
some USB bus sniffing to see what's going on behind the scenes.
* Update device->streaming to reflect whether we're streaming data,
rather than just whether the streaming thread is active.
The streaming thread is now always active!
On at least freebsd-13 trying to cancel a transfer whilst the libusb thread
is not running results in the transfers not completing cancellation.
The next time they're attempted to be re-added the libusb code thinks
they're still active, and returns BUSY on the buffers.
This causes gqrx to error out when one makes DSP changes or stops/starts it.
You have to restart gqrx to fix it.
After digging into it a bit, the libusb code expects that you're actively
running the main loop in order to have some deferred actions run in the
context of said main loop thread. This includes processing cancelled
transfers - the callbacks have to be run (if they exist) before the
buffers are properly cancelled and have their tracking metadata (a couple of
private pointers and state) removed from inside of libusb.
This patch does the following:
* separate out adding and cancelling transfers from the libusb worker thread
create/destroy path
* create the libusb worker thread when opening the device
* destroy the libusb worker thread when closing the device
* only add and cancel transfers when starting and stopping tx/rx
* handle cancelled transfers gracefully in the USB callback
Whilst here, also make the libusb device memory zeroed by using
calloc instead of malloc.
This fixes all of the weird libusb related buffer management problems
on FreeBSD.
HackRF One supports arbitrary sample rates from 2 Msps to 20 Msps. In
early development we had ideas about preferred sample rates that we no
longer consider valid.
The checksum calculation process was causing the CPLD configuration to reload from flash. With the new SRAM loading mechanism, flash contents may not be up to date, so the CPLD bitstream may regress to the point of not working or not working correctly. This commit is a short-term fix for mossmann/hackrf issue #609.
fixes#435, osmosdr calls hackrf_exit for the last sink and the last
source. If both are in one flow graph the desctructor of the source
fails as the sink already closed the usb context.
This prevents hackrf_exit to close the context if not all devices are closed
this allows to remove function cast at prepare_transfers()
missing 'LIBUSB_CALL' produced problems in debugger with Visual Studio 2017
Signed-off-by: hayati ayguen <h_ayguen@web.de>
